You are thinking in the wrong direction
Amazon's playbook with a special, an insider guest
“Let’s see what we have to work with and then see what we can do”
This is how most companies approach business.
“Let’s see what we absolutely want to do and then see how to get the resources”
At Amazon, the logic is backward.
See, in Amazon, people think first about which value they want to provide the customer. Then they look to find the resources and skills they need to provide it.
And they have 3 tools that help them achieve that, which we will review today.
P.S.
We have an insider who will tell us which of these tools are still relevant in Amazon today.
The insider is
, and everything he writes is his own opinion.Tool #1: The Product Development Proposal
Picture this:
You and your team come up with a great idea for a product that will make the customers’ lives so much easier.
Instead of pitching it to the product team and deciding how to proceed, you need to write a document that consists of two parts: a press release and a set of frequently asked questions.
You might think: “Bleh. So much for being lean and moving fast.”
Worry not. This document is actually a good practice to verify your own thoughts. Bear with me and you’ll see.
Press Release
Imagine how will the product look in its final form. Then write a hypothetical press release that reveals the product to the public.
The press release describes what the product is and the benefits to the customer. (Working backwards again)
Frequently Asked Questions
This part includes the questions that you anticipate your coworkers and customers will have about the product.
When you think about the final form of the product and why it might not work (The questions), you better understand your idea, the obstacles and the costs.
Here you can find a public six-pager template with an example.
Insider take:
As an engineer, I've been involved in PR/FAQs of different initiatives that we'd later implement. You can argue why a feature is good from a product or business standpoint... But does the customer really care about that?
Additionally, it's not only a marketing tool to say that you think about the customer a lot.
From an engineer’s point of view, it’s useful to ask questions in early reviews of a PR/FAQ that later make their way to the FAQs. You are frontloading those ambiguities to make sure once an engineering team is going to work on it, the idea is more mature
Tool #2: The Deep Thinking Document
To propose any course of action, Amazon’s employees are expected to write a detailed argument in a Deep Thinking Document (DTD) (Also known as the “Six-Pager”).
The idea of the DTD is to convey complex ideas that a slideshow cannot.
Each meeting that has a DTD includes a few minutes of silent read-through, in the beginning, to let people catch up to speed with the proposal.
Now, what’s the difference between the DTD and the PR/FAQ, you might ask. I’ll let our insider answer:
The PRFAQ is a bit like “fake it until you make it”. You put yourself in a hypothetical scenario and think what would the customer say or ask. It’s kind of daydreaming without tied to reality. Then from that “dream” you work backward to see how could you make it.
The 6-pager is more of a down to earth document, with a heavy importance on metrics and data. On an initiative you’d break it down into objectives, clear KPIs to measure, break it down into milestones to achieve.
Insider take:
“There is no way to write a six-page narratively structured memo and not have clear thinking”
- Jeff Bezos
I agree on that one with Bezos.
Even if you don’t write in substack, I’m sure you have found the answer to a question in the process of writing the question to ask someone else.
Writing clarifies your thinking. And it’s important to create a culture where creating a well-written document is not seen as a waste of time.
This kind of document isn’t created for a team to read one day and forget it. These are the documents shared with tons of stakeholders, high leaders and people without the context or the time to get the context.
Ideas have to be in their simplest and purest form.
Tool #3: Big-Picture Planning
At Amazon, the highest-level executives set some broad goals that all teams in the company can work toward.
“Hit 600B revenue mark this year”
Then leaders from each team write a DTD, proposing several strategies and projects.
Then the executives review these proposals and the highest-level executives choose a certain number of them to prioritize over the others.
Insider take:
At a big scale, you can’t granularly track all the low-level details each team is working on. But you still want to maintain a sense of direction.
You need high-level goals owned at a high leader level (VP, director…) and later that goal is completed by smaller actions in a smaller scope.
Many projects can hit a goal.
- You want an increase in revenue? A single project won’t cut it.
- You want to reduce latency on the page? You need multiple projects to reduce it and guardrails to make sure no project introduces it back.This is also useful for engineers. By knowing clearly what the organization goals are, you can quantify your impact by tracking against that goal.
If you reduce latency by 200ms and there’s a goal of reducing 1s that year, then you have completed 20% of the goal with that project.
Final words
It’s no secret that Amazon is a force to be reckoned with.
Every year since 1998 Amazon has released a shareholder letter, to let them know how Amazon is doing, future plans and mistakes made.
Much like Warren Buffet’s letters.
Interesting to read how Bezos approached business during difficult times, like the dotcom bubble and the housing crisis (2000-1 and 2008-9).
You can find all the letters here.
What we enjoyed reading this week
 | A guest post by
|
Great article Fran and Orel. I've found myself implementing the "Working backwards" framework so much more as I've tried to increase how much I better prioritize.
For example, we want to ship to customers by <x> date, that means we need to internally experiment by <y> date, which means we need to be eng complete by <z> date, and have comms ready by another date, etc. once we do all of that planning backwards, we know exactly when we need to do each step, and if we stack rank into p0s, p1s, p2s, etc. we know what we can cut if we're not meeting it, and what good vs. great looks like.
It's cool to see how Amazon makes the working backwards practice part of the cultural norms
Nice article ,well written found it quite insightful