Tag: Amazon

Working Backwards at Amazon

Amazon’s catalyst for innovation lies in its perspective to always think from the customer backwards. That’s how most successful projects get done, and it all starts with the commonly used Amazonian phrase, working backwards.

Before building a charter, a project plan and setting out timelines, the first artifact that a customer-centric project entails is the publication of a Press Release and FAQ, or PRFAQ for short. This mechanism allows key decision makers to start with what the customer experience articulated through the press would sound like, using the journalism practice of being concise, with the most important paragraphs outlining the entire program, and why customers would get excited about it. This is part of one of Amazon’s most important leadership principles, customer obsession.

Defining the customer experience through the PR, which is no more than six pages, you work backwards and build out the associated FAQ, where you dive deeper into common questions and answers. The FAQ section is where you would outline and iterate on the tough questions that you would anticipate people would ask, by preemptively answering them.

One notable omission in Amazon’s tooling for being customer obsessed, is the lack of PowerPoint presentations, as Colin Bryar and Bill Carr explain, in their book Working Backwards : Insights, Stories, and Secrets from Inside Amazon:

What if we thought of the product concept narrative as a press release? Usually, in a conventional organization, a press release is written at the end of the product development process. The engineers and product managers finish their work, then “throw it over the wall” to the marketing and sales people, who look at the product from the customer point of view, often for the first time. They’re the ones who write the press release, which describes the killer features and fantastic benefits and is designed to create buzz, capture attention, and, above all, get customers to leap out of their chairs to buy.

The authors explain that as most companies take the approach of coming up with a product or business idea that is great for their organizations, they then try to spin a positive light as to why there are unmet customer needs, rather than the other way around. “If the two organizations had started the process by writing a press release, they would have had to agree on the features, cost, customer experience, and price. Then they could have worked backwards to figure out what to build, thereby surfacing the challenges they would face in product development and manufacturing.”

Amazon LPs: Learn and Be Curious

Amazon’s Leadership Principles, or LPs help its employees hold themselves and each other accountable, through tangible and measurable qualities that guide and lead decision-making, with customers at the forefront. 

This article will focus on the principle of Learn and Be Curious. 

What is learn and be curious?

Amazon’s official quote for this principle is:

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Amazon Leadership Principles

Both personally, and collectively as a team, launching products, learning is a continuous development and does not end when the project ends. Personally, you look at this LP as a way of always learning from experiments, observing an outcome based on inputs, and adjusting your control levers. This holds true collectively as a team as well, where Amazon has what we call mechanisms.

While I will dedicate a full article on mechanisms in the future, suffice to say akin to how agile works, mechanisms provide a framework for building products consisting of working backwards from the customer’s point of view (the ideal outcome we would publish in a press release), in order to keep focusing on what matters to the customer. This is what we at Amazon call, working backwards.

If you cannot explain what you are building in a way that prospective customers would embrace, then you probably don’t have a good justification for this idea.

Switching back to mechanisms, Amazon bakes into its DNA control mechanisms like the very effective and prominent, Correction of Error (COE). Correction of Error is a process for improving quality by documenting and addressing issues. You will want to define a standardized way to document critical root causes, and ensure they are reviewed and addressed.

  • What happened?
  • What was the impact on customers and your business?
  • What was the root cause?
  • What data do you have to support this?
  • What were the critical implications, especially security?
  • What lessons did you learn?
  • What corrective actions are you taking to prevent this from happening again?

Planning for Edge Cases, by Using Amazon’s ‘Dogs Not Barking’ Technique

When writing formal annual planning documents at Amazon, Operational Planning 1 (OP1), there is an FAQ that is always inserted, and it is more of a phrase, “Dogs not barking”. It is an essential FAQ item to help ensure the author or authors of the OP1 document cover not just the obvious topics and initiatives, but also account for the outliers. In it’s essence the phrase means:

A situation where the absence of a signal communicates something important.

Analogously, there is this famous quote, “The squeaky wheel gets the grease”. The quote probably comes from a famous book, The Adventure of Silver Blaze by Sir Arthur Conan Doyle.

The inspector in the book, Gregory asks, “Is there any point to which you would wish to draw my attention?” Holmes responds, “To the curious incident of the dog in the night-time.” But, protests the inspector, “The dog did nothing in the night-time.” To which Holmes responds: “That was the curious incident.” For Holmes, the absence of barking is the turning point of the case: the dog must have known the intruder. Otherwise, he would have made a fuss. The point is, to pay attention to what isn’t there, not just what is, and this requires intentional focus to be drawn.

The Amazonian ritual of writing FAQs to accompany formal planning or proposal documents is definitely something I would encourage you to incorporate into your workflow, and this is certainly one thoughtful question that would encourage peripheral accountability.