Working Backwards

Where it came from

Amazon, in the years around 2004. Before a team could build a new product, they had to write the press release announcing it as if it had already shipped, and then the list of questions a sceptical customer or journalist would ask about it. The document was usually six pages. If the press release wasn’t something a customer would want to read, the product wasn’t built, and if the questions couldn’t be answered, the team went away and worked out how.

The Kindle was developed this way, and so were most of the products Amazon launched over the following fifteen years. Colin Bryar and Bill Carr, who ran the process from the inside, wrote it up in a 2021 book of the same name. Inside Amazon the document is still called the PR/FAQ.

The idea is older than Amazon. Any good engineer designs from the requirement back, and any good cook reads the recipe from the plate. What Amazon added was the rule that you write the ending first, in the customer’s words, before anyone is allowed to fall in love with a way of getting there.

Why it works

Most plans fail before they start, because "done" was never defined. People begin with the first step because it is the one they can see, and by the time they look up they have built a great deal of something that turns out not to be the thing.

Starting from the finished thing forces you to describe success concretely, as a state of the world somebody could observe, and to name who would have to agree it is done. Done is a judgement a particular person makes, not a feeling the team has. Then walking backwards gives you the plan for free, because each step is simply "what has to be true just before this?". A milestone that doesn’t say what it stands on is a list item; one that does is part of a walk.

When to reach for it, and when not to

Reach for it when you are setting out to make something that will finish, or aiming at a goal you can picture. It is especially useful when a lot of people have opinions about how to do the thing and nobody has said what the thing is.

It is less useful for a problem to be diagnosed, where the end state is "the problem has gone" and the work is all in finding out why it is there. Use 5 Whys or the fishbone for that. In Greggle, Working Backwards is suggested second on a Project and on a Goal, after a Pre-mortem.

How to run it

With a pen, on one sheet of paper.

1. Write done as a state of the world, not an activity, dated in the future, as a stranger would report it. Name who would have to agree it is done.
2. List the evidence that would prove it. Numbers where there are numbers. Something a person outside the work could point at.
3. Write the questions a sceptic would ask. How much did it cost? What went wrong? Why hasn’t someone done this already? Answer each honestly, and notice which you can’t.
4. Now walk back. What has to be true just before that ending? Write it as something that has become true, say how you would see it, and say what must already be true just before it.
5. Keep walking until the chain touches today. Then say honestly where you actually are, which is rarely where the chain assumed.
6. Name the first move, the one you could make this week from exactly here, and write down what the chain still assumes.

There is a one-page card with these steps and a blank grid to fill in, made to print on A4. Or the PDF.

On a Greggle board

Pick Working Backwards on a Project or Goal board and Greggle proposes three steps: the ending, the walk back, and where it meets today. The walk starts with three milestones and takes up to twelve.

the top boarda step with steps inside opens when clicked

Open 2 — The walk back

← Back up a levelinside 2 — The walk back

Nothing is added until you have looked at it. Open any step and it becomes a board of its own. Steps that cannot sensibly be cut smaller get marked as actions, and every action collects in one flat list.

What the check looks for

One button reads the whole branch back. On this method it reports, among other things:

• Milestones have been written and not one says how you would see it. A milestone nobody can see is passed without anyone noticing.
• Not one milestone says what must already be true first, which means this was written forwards and reversed, or is simply a list.
• A milestone just says the goal again instead of being a step on the way to it.
• A milestone carries a hard deadline with nothing behind it.

A worked example

Where it falls down

It is only as good as the honesty of the ending. If you write the announcement you wish were true rather than one you could earn, the plan inherits the wish, and every backward step is a step towards a fantasy. The sceptic’s questions are the protection, and the question people most often skip is "why hasn’t someone done this already?".

The other failure is a walk that stops in mid-air. A chain whose earliest milestone is still months away is a plan for the second half of the work. Keep going until a milestone touches something you could do this week, and then say where you really are, which is what the "what the chain still assumes" question is for.

Pairs well with

• Pre-mortem. Greggle suggests the pre-mortem first on a Project, then this. Write the ending, walk back, then imagine it failed and see what the walk missed.
• Objectives and Key Results. The evidence list is a set of key results. If a goal has no end date, OKRs are the better frame.
• Issue Tree. When a milestone is too big to see, split it into parts that don’t overlap.