The Amazon Working Backward Process for Engineering
The working backwards process is the key mechanism Amazon uses to ensure that the right projects are funded. This same process should be used by engineering teams for their work.
The working backwards process at Amazon is famous. It's core to the way that product managers have identified and communicated all big and small ideas over the years.
The core of the process is that you start with the customer, identify their problem, and work backwards towards a solution. Seems simple, right?
I'm going to walk through the working backwards process briefly. Then I'll explain how it should (but often doesn't) apply to the engineering process.
At Amazon, the core document for the working backwards process is the PRFAQ (Press Release - Frequently Asked Questions).
Most documents followed this basic format.
Problem Statement - "Customers hate long checkout lines."
Solution Statement - "We're going to let people just walk out of a store."
How it works - "We will use a combination of phones, sensors, and biometric data to identify a customer, what they pick off a shelf, and then charge them."
FAQ - A long list of questions and answers to explain all your inevitable questions. For Example, "What if someone puts an item back on the shelf?"
As you read through the document, you start with the customer, understand their needs, and then work towards the planned solution.
The Why for Working Backwards
Why does the working backwards process work so well for product management? Why do people insist on the PRFAQ document?
One big reason is that we're typically too caught up in what we can do, instead of thinking of what our customers need.
Imagine you're a product manager for Amazon. You look at Amazon's recommendation engine, the stored wallet, and at the shipping system. You have a great idea.
"We could use our recommendations, combined with our shipping system, to automatically ship the highest recommended items to customers! If they don't like the item, they can just ship it back for free. Otherwise, we charge them for the item."
What a great idea! That uses three already built systems at Amazon to build a new revenue generating product at Amazon. It shouldn't be too hard to build. The revenue generated could be spectacular.
Except it sucks for customers. This example may be obviously a bad idea, but slightly less horrible variations of this are regularly proposed.
The problem is that the product manager started with a potential solution, instead of starting with a customer need.
Do customers have any unmet need to have random products dropped in their doorway? Is this solving any outstanding issue or opportunity for a customer?
Products make sense when you're generating the approach by starting with the customer. When you start at what's possible, you're in for a world of hurt.
Engineers have the same choices to make, and encounter the same issues.
Deciding where to invest as engineers
For most engineering teams, there are two sources of work.
The Product management queue.
The product management queue is already managed by (hopefully) customer need, working backwards, etc.
Engineering related projects are the projects the engineering team pushes for. Rebuilding X system, building Y metric system, or switching to Z technology.
Even more than product managers, I think engineers can mistakenly look at capabilities before they look at real need.
"Kotlin is a fantastic new language. We need to start using it."
"We've barely touched on the possibilities of machine learning. We should apply it."
"We could rebuild the system with an event-based architecture."
Engineers build software for a living. They're tied into the details of how things are built all day long. This means that the engineering team is already biased towards thinking of what could be built.
I'm not claiming that these projects come without a prior need. The issue that arises is that there is a quick fit of a potential solution to a non-clear issue.
"Feels hard to maintain. Let's rebuild it in Kotlin! Rebuilding in a newer language will improve it!"
That's vaguely identifying a problem, and immediately slapping a solution onto it. Where does the engineering team spend their time in this case? They'll spend all their time investigating how the rebuild should work, and how Kotlin might change things. They've immediately run past the problem statement and started working on execution details.
Who's the customer?
Product managers have an easier mental challenge to overcome. They know their job is to represent the customer. If you're the product manager for Gmail, you know that your customer is people who use Gmail. Customer obsession comes easier.
Engineering teams have a harder time identifying the customer, and identifying how to speak about those customers.
Who are examples of customers for an engineering team?
The engineering team itself - When you're supporting a product, in some ways your first customer is your team. You can't properly support a product if it's hard to support. What does your customer care about? Ease of diagnosing external customer issues. Ease of changing code. Ease of ramping up new employees. A variety of things which makes engineering better.
The product managers - Product managers are a customer of the engineering platform. They need features built, updated, and removed. How much each change "costs" in engineering effort is under the control of the engineering team.
The company itself - Depending on your product, your software may be a relatively major cost to the company. Licensing or hardware costs can be a decent sized line item in the budget.
External customers - The engineering platform often impacts customers directly, with latency, or error rates. If customers interact directly with your platform, one of your customers is the customers themselves.
Considering this complex pool of customers, engineers have a need to clearly articulate the problems each type of customer is experiencing, to ensure that prioritization can be done effectively.
How to work backwards as an engineering organization
For every item of work, you should start with the customer.
What is the exact problem you're solving? Describe it.
What is the current impact of the problem? What is the available opportunity?
How can you measure the current problem, and how can you measure a potential improvement? What is the current status specifically? What is the future status?
How does this problem priority rank vs. your other priorities?
Don't begin solving the problem before you've done the above. Why?
When you have a solution in mind, you'll find yourself fitting the problem to the solution, instead of the other way around.
"We should upgrade our servers. Why?"
"Well.. because it'll reduce latency. And that's good for customers."
Is reducing latency good for customers? Yes. Will upgrading the servers reduce latency? Yes.
But was reducing latency for customers one of your top problems? Maybe, maybe not. Regardless, you're fitting your problem (and impact, and measurements) to the specific thing you're doing, instead of starting at the need.