Working Backwards: building from the outcome

I recently read Working Backwards by Colin Bryar and Bill Carr. The book is about how Amazon built many of the systems and processes that helped it scale.

But what interested me wasn’t really Amazon. It was the way they think.

I’ve always liked solving problems by asking, “How can we make this work?” This book made me ask a slightly different question: “What should the end result look like?” And then work backwards from there.

Start with the customer

One of the ideas that stayed with me is deceptively simple: start with the customer and work backwards.

Most people start with what they have. “We have this technology.” “We can build this feature.” “We have developers available.” “Let’s create something around it.”

Working backwards flips that. You start with the problem.

• What does the customer actually want?
• What would make their life meaningfully better?
• What would the experience look like if the problem were already solved?

Only then do you figure out how to build it.

1. The customer’s problemstart here
2. What “solved” looks like
3. What to build

This sounds obvious. But I think it’s one of those things that becomes much harder when you’re actually running a business. Once you have people, technology, money, existing processes and deadlines, it’s very easy to start optimising around what already exists.

Write before you build

One of my favourite ideas from the book is Amazon’s use of the PR/FAQ. Before building something, the team writes the press release describing the product as if it already exists. Then they write the FAQ.

It forces a very uncomfortable question: “What are we actually building, and why should anyone care?”

I love this. Because building is easy compared to deciding what deserves to be built.

You can spend weeks designing something that nobody really needs. You can spend months developing a feature that solves the wrong problem. You can build an incredibly efficient system for doing something that shouldn’t exist in the first place.

Writing forces you to think before you spend resources. And that applies far beyond software:

• Before hiring someone, write down what problem the person is supposed to solve.
• Before creating a new service, define what the customer gets.
• Before building an internal process, understand why the process exists.
• Before starting a company, describe what changes for the customer if the company succeeds.

Clarity is surprisingly powerful.

Don’t confuse activity with progress

This connects with something I learned from The Goal: a company can be extremely busy and still not be moving forward.

Working Backwards made me think about this from another angle. There is a difference between inputs and outputs. Inputs are the things you do. Outputs are what actually changed.

Inputs · what you do

• Calls made
• Features shipped
• People hired
• Emails sent
• Hours worked

Outputs · what changed

• Customers acquired
• Problems solved
• Revenue generated
• Customer experience improved

The danger is that inputs are easier to control and measure. So companies naturally start obsessing over them.

But the customer doesn’t care how many hours your team worked. They care whether their problem was solved.

Mechanisms over motivation

Another idea I found interesting was Amazon’s obsession with mechanisms. Instead of relying on people to remember things, or constantly reminding everyone to do the right thing, build a system that makes the right behaviour more likely.

That’s a very different approach to management.

Imagine a team repeatedly forgetting to update a project. You can tell everyone, “Please remember to update the project.” Or you can build a process where the update naturally becomes part of the workflow.

One relies on memory. The other relies on a mechanism.

I naturally lean towards the second approach. Maybe that’s why I enjoy automation so much. If a task happens repeatedly, I immediately start wondering: “Why does a human have to remember this?” If something can be turned into a system, it probably should be.

Not because humans are unnecessary. Quite the opposite. Human attention is valuable. It should be spent on decisions, creativity and problems that actually require judgement — not on remembering to copy information from one spreadsheet to another.

Small teams can move differently

The book also talks about Amazon’s approach to small, autonomous teams. The basic idea is that teams should be small enough to communicate effectively and have clear ownership over what they are responsible for.

I found this particularly interesting because of how companies change as they grow. At a small company, everyone knows what’s happening. Then the company gets bigger. More people join. More meetings appear. More approvals are needed. More people become involved in decisions.

Suddenly, a simple task requires five people and three meetings. Growth can accidentally create bureaucracy.

The solution isn’t always to work harder. Sometimes it’s to redesign the system:

• Give smaller teams clear ownership.
• Give them the information they need.
• Let decisions happen close to the problem.
• Make the person responsible for the outcome actually responsible for the outcome.

The founder should not become the bottleneck

This is probably one of the most practical lessons for me. A company that requires the founder to make every decision isn’t really scalable.

At some point, the founder becomes the bottleneck. Every question, every client issue, every hiring decision, every operational problem comes to them. And eventually, the company can only move as fast as the founder can respond.

That’s not a people problem. That’s a system design problem.

The answer is not simply “delegate more”. It’s to build enough context, ownership and mechanisms that people can make good decisions without constantly asking for permission.

That’s a much harder problem. But it’s also a much more interesting one.

High standards are a system too

Another part of the book that stood out to me was Amazon’s approach to hiring. The idea isn’t simply to find someone who can do the job. It’s to maintain a high standard for who gets added to the organisation.

This matters because people don’t just add output. They also influence how everyone else works. One great person can raise the standard of a team. One person who consistently accepts mediocre work can lower it.

Culture isn’t only what you write on a wall. It’s what gets repeated, tolerated and rewarded.

Working backwards applies to almost everything

The more I thought about the book, the less it felt like a book about Amazon. The framework can be applied almost anywhere.

• Building a product? What does the customer need at the end?
• Designing an internal process? What outcome should this process produce?
• Hiring? What problem does this person need to solve?
• Automating something? What should happen without human intervention?
• Starting a business? What would be different for the customer if this business didn’t exist?
• Stuck on a problem? What does success actually look like?

Then work backwards.

The biggest lesson

I think the biggest lesson I took from Working Backwards is that good execution starts before execution. It starts with clarity.

• Before building the product, understand the customer.
• Before creating the process, understand the outcome.
• Before hiring the person, understand the problem.
• Before adding another tool, understand what you’re trying to fix.
• Before scaling the company, understand what is actually working.

I’ve always been interested in making things work. Working Backwards made me more interested in understanding what “working” is supposed to mean in the first place.

Maybe that’s the real advantage of working backwards. You stop asking, “What can we build?” And start asking, “What should exist when we’re done?”

Then you work backwards.