Working Backwards is written by two people who spent years inside Amazon, close to Jeff Bezos. It’s about the specific habits and processes Amazon used as it grew. I wrote a longer post about it, Working Backwards: building from the outcome. This page is my notes on the parts that stayed with me.

What I liked is how practical it is. Lots of companies say they care about customers. This book is about the mechanics: the documents, the meeting formats, the hiring process, the way teams are set up. It’s an operations book about how to make a culture actually happen.

Start with the customer, then work back

The main idea is in the title. Most teams start with what they have. A technology, a feature idea, some developers who are free. Then they look for a customer who might want it.

Amazon tries to do the opposite. Start with the customer and the problem. Describe what “solved” looks like for them. Only then work out what to build.

It’s obvious when you say it. But it gets much harder once a company has people, money, existing systems and deadlines. It becomes very easy to keep optimising around what already exists.

The PR/FAQ

The tool they use for this is the PR/FAQ. Before building something, the team writes a press release for it, as if it’s already launched. Then they write a list of frequently asked questions, both from customers and from inside the company.

The press release forces you to explain, in plain language, who it’s for and why they should care. The FAQ is where the hard questions go: how much it costs, what could go wrong, why now, why us.

The book says most PR/FAQs never get built, and that’s the point. It’s much cheaper to kill an idea at the document stage than after six months of building it.

I like this a lot because building is easy compared to deciding what deserves to be built. And it applies outside products. Before hiring someone, write down what problem they’re there to solve. Before starting a new process, write down what it should produce.

Narratives, not slides

Amazon banned PowerPoint in senior meetings. Instead, someone writes a memo of up to six pages. The meeting starts with everyone reading it in silence. Then they discuss it.

The reasoning is that bullet points let you skip the hard parts. You can put three nice-sounding points on a slide without ever explaining how they connect. A written narrative doesn’t let you do that. If your thinking has gaps, they show up in full sentences.

Reading in the room also means everyone has actually read it, which honestly solves half the problem with most meetings.

I’ve noticed this in my own work. When I can’t write a process down clearly, it usually means I don’t understand it well enough yet.

Inputs and outputs

This was the part I found most useful. Amazon separates output metrics from controllable input metrics.

Output metrics are things like revenue, profit, or growth. They matter, but you can’t control them directly, and by the time they move it’s too late to do much.

Input metrics are the things you can actually act on, which then drive the outputs. Things like how many products are in stock, how fast pages load, how quickly orders ship. If you get the inputs right, the outputs follow.

The tricky part, which the book is honest about, is picking the right inputs. They give an example where a team was measuring the number of product detail pages, which went up nicely without helping customers much. They had to change the metric to something closer to what customers actually experienced.

This connects to something I learned from The Goal: a business can be very busy and still not move. Measuring the wrong input is one way that happens.

Single-threaded leaders

Another idea I hadn’t seen before: the single-threaded leader. One person whose only job is one initiative, leading a team that’s dedicated to it.

The problem it solves is something I’ve seen in small companies. A project belongs to someone who also has five other responsibilities. So it gets attention when there’s time, which is never. Nobody is fully responsible for it, so it drifts.

Amazon’s answer is to give it one owner with nothing else to do and a team that can move without asking permission from other teams every week. They connect this to the two-pizza team idea: small teams that own something end to end, so they need less coordination.

Bar raisers

Their hiring process has a role called the bar raiser. It’s someone from outside the hiring team, trained for this, who sits on the interview loop and has the power to say no.

The reason is that hiring teams are under pressure. They need someone now, so they lower the bar a little. Then a little more next time. The bar raiser is there to protect the long-term standard from short-term urgency.

I found this interesting because it’s another example of a mechanism. Instead of telling people “hire well”, they built a role that makes it hard to hire badly.

Mechanisms over good intentions

That might be the biggest thing I took from the book. Amazon has a saying, roughly, that good intentions don’t work and mechanisms do.

If a team keeps forgetting to update a project, you can remind them every week. Or you can build the update into the workflow so it happens anyway. One relies on people remembering. The other relies on the system.

I naturally lean towards the second. If a task keeps happening, I want to know why a human has to remember it. This book gave me a better vocabulary for that instinct.

The founder as the bottleneck

The last thing is personal. If every decision in a company comes back to the founder, the company can only move as fast as the founder can reply.

“Delegate more” is the usual advice, and it’s not enough on its own. People need context, clear ownership and mechanisms so they can make good decisions without checking first. That’s harder to build, and it’s the part of operations I find most interesting.

What I’m taking from it

Write the press release before you build anything.
If you can’t write it in full sentences, you probably haven’t thought it through.
Measure inputs you can control, and check they actually move the output.
Give important work one owner who has nothing else.
Build mechanisms. Don’t rely on reminders.

What I took from it