Amazon writes the press release before the build

A product team can find out whether an idea is clear before anyone is assigned to build it. Werner Vogels described the process Amazon was using, in a post on 1 November 2006, and he called it Working Backwards.

In that post he is writing about Amazon's fine-grained services. A service there is both software and a team. Ownership is strong, the groups are small, and he says that combination is meant to make innovation easier. He treats the services as small startups inside the larger company. Each one has to know its customer, and he includes customers inside Amazon as well as customers outside it. The process keeps the service matched to what that customer needs. The goal he names is simplicity, through a continuous and explicit focus on the customer.

Working Backwards starts with the documents you would need on launch day, then moves toward documents closer to implementation. The press release and the FAQ come first. He says those pages flesh the idea out and force clarity about what the team will build. He lists four steps.

The press release comes first, and he says to nail it. It states what the product does, why it exists, and what the features and benefits are, clearly and briefly. Writing it at the start shows how the world will see the product, which can differ from the way the team already talks about it. An internal initiative can use the same page, because he has already counted internal customers. Name the team that will use it, say what changes for them when it exists, and say why it is worth having. A draft that only the sponsors can follow has not yet shown the product to anyone else.

The FAQ is the test that sits on top of that page. Vogels calls it meat on the skeleton. It collects questions that came up while the press release was written, questions other people asked when they read it, and questions that define what the product is good for. He also says to stand where a user stands and add the questions that person would have. A question with no answer is a hole in the product, found while the cost is still a document. An answer that adds a feature the press release never mentioned means the offer is still moving. Either result is cheaper here than it is after people have been assigned to build.

If the press release and the FAQ hold, describe the customer experience in detail. Where there is a screen, mock up each one the customer uses. For a service, write use cases, including short examples, that show someone solving a problem with the product. Then write the user manual, which he describes as the document a customer uses to learn what the product is and how to use it. He gives it three sections: concepts, how-to, and reference. More than one kind of user means more than one manual. An internal tool often has two readers, the person doing the work and the person who approves it, and the two manuals show whether you have described one product or two.

Once that pack exists, Vogels writes, it is much clearer what you plan to build, and you can explain it to other teams. The test he states at the end is a shared picture of the product. Outside Amazon, keep the same order before a build is staffed. Write the press release for a named customer. Build the FAQ from the writing, from the readers, and from a user in the middle of the job. Stay with those two documents while the answers are still fuzzy. When they are solid, add the experience and the manual, and take the set into the meeting that would otherwise approve a build from a slide.

A lean startup and product sprint is a practical place to write the press release and the FAQ for one live idea, with the sponsor and the people who would use it, before anyone staffs the build.