Working Backwards

How Amazon kicks of product development

When to run: Working backwards?

Working backwards is a framework for how to think about product without lengthy roadmaps that end up being scrapped. It’s a way to short-circuit the traditional product development track, and make sure that you build something that your customers will actually care about.

Why work backwards?

Use working backwards to flesh out a concept and achieving clarify what you will build.

How to work backwards

For new initiatives a product manager starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product’s customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centred around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.

You will need to break down the high-level problem you’re solving and visualize the finished product.

  1. Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists - what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product - not just how we think about it internally.
  2. Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
  3. Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.

Concluding notes

References