Start from the customer.
Then tell the agents what to do.

The situation

Most teams start from a tool. A new model drops. Someone opens an agent. Features appear. A demo looks impressive. Then nobody can say, in one sentence, which customer is better off and how you would know.

I spent nine years at Amazon writing and reviewing Working Backwards documents. The method is not a ceremony. It is a forcing function: you cannot hide behind a feature list when you have to write the launch as if it already happened, for a person who does not work here.

Agents make that forcing function more valuable, not less. Generation got cheap. Clarity did not.

What Working Backwards is

Amazon has used this process on major products since the mid-2000s. Colin Bryar and Bill Carr later described it in public in Working Backwards. Werner Vogels has written the same sequence for years. The idea is simple enough to fit in one line:

Define the customer experience first. Then work backwards until you know what to build.

The main tool is a PR/FAQ: a fictional press release plus the hard questions a customer and an executive would ask. You write it before you commit a team. You revise it until the thinking is tight. Only then do you spend the expensive work.

That is the opposite of how most AI work starts. Most AI work starts with “what can the model do,” then hunts for a use case. Working Backwards starts with “what would make a specific customer’s life better,” then decides whether an agent belongs in the path at all.

Why this fits agents perfectly

An agent is a very fast intern with no memory of your customer. It will do what you ask. It will not notice that you asked for the wrong thing.

That is why Working Backwards maps onto agent execution better than a backlog of tickets:

• The press release is the destination. You do not brief an agent with “build a chatbot.” You brief it with the customer outcome you would be willing to put your name on.
• The FAQ is the eval. Every hard question becomes a test the agent — and later the product — must survive. “What happens when the model is wrong?” is not a slide. It is a check.
• The customer experience is the interface contract. Agents generate screens and flows cheaply. The PRFAQ tells you which of those are in service of the person, and which are decoration.
• Building backwards is how you spend tokens on purpose. Spec-first work wastes fewer cycles because the agent is coding against a decided problem, not exploring one.

I have watched teams skip this and call the skip “moving fast.” What they get is a pile of generated artifacts and a demo that cannot answer the first customer question. Speed without a destination is just spend.

What changed in the agent era — and what did not

Amazon’s own leaders have said out loud what many of us felt last year: sometimes it is now cheaper to build a working prototype than to write a six-page PRFAQ about an idea you have never touched. Werner Vogels has written that when you have conviction about the customer problem but genuine uncertainty about the approach, you can start with a prototype, use it the way a customer would, then write the document from something real.

That is an amendment to the sequence. It is not a repeal of the method.

The cheap prototype is research. It is how you stop inventing a product in your head. It is not permission to skip the customer, skip the FAQ, and ship whatever the agent produced on Tuesday.

Use the prototype to learn. Then write the press release as if a stranger will read it. If you cannot, you do not have a product yet. You have a demo.

How we run it

In the AI Native Practitioner Programme, pods do not start with a feature list. They start with five customer questions, then a PRFAQ, then a live narrative review. The document is torn apart if the bar raiser will not approve it. Agents help draft. Humans defend it.

That PRFAQ then becomes the spec the engineers feed into agentic workflows. The FAQ questions become the evals. If the team cannot launch with quality, they write a Correction of Errors instead of pretending the demo was the product.

This is the same mechanism I ran inside Amazon, adapted for people who now have agents on the desk. The customer still comes first. The writing still has to survive silent reading. The agent still does not get to decide what “good” is.

If you lead a team that already has the tools and cannot get them to stick, that is a different problem — a human one. The AWS Berlin case is how adoption actually spread, without mandates or usage dashboards.

A one-page brief you can use tomorrow

Before you open the agent, write these five lines. If you cannot, do not start the build.

1. Customer: one person, not a segment slogan.
2. Change: what is true for them after this that is not true today.
3. Proof: the number or behaviour that would make you keep the product.
4. Failure: the question you are most afraid a customer will ask.
5. Out of scope: the impressive thing you will not build this time.

Then paste that into the agent as the spec. Ask it to draft the press release and the FAQ. Read both in silence. Edit until a sceptical colleague would not flinch. Only then let it write code.

That is Working Backwards for people who execute with agents. The method did not get old. The cost of skipping it did.

Public sources for the method, not a substitute for practice: Bryar & Carr, Working Backwards; Amazon’s own account of the PR/FAQ process; Werner Vogels on working backwards from the customer and, more recently, on prototypes when the approach is uncertain. WonderLead is independent of Amazon.