“We start with the customer and we work backward”, that’s how Jeff Bezos describes their product philosophy.  But what does that mean in practice?

Thankfully my Quora Weekly Digest contained an old thread about Amazon Product Management, and the top answer (by Ian McAllister, a senior product leader at Amazon) was fascinating.  It talked about how they start by trying to put together a press-release first:

For new initiatives a product manager typically 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 centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.

If the benefits listed don’t sound very interesting or exciting to customers, then perhaps they’re not (and shouldn’t be built). Instead, the product manager should keep iterating on the press release until they’ve come up with benefits that actually sound like benefits. Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!).

The rest of the answer goes into more detail about the press release.  

While doing a little more searching on the topic I discovered a great post from 2006 by Amazon’s CTO Werner Vogels that describes their “Working Backwards” process at a higher level.  Writing the press-release is just step 1.  There are four steps to complete before they start building the 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.
4. Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.

The really interesting thing here is to compare it with the Lean Startup approach.  Both are customer centric.  But the Lean Startup approach aims to put a concrete prototype in front of consumers to validate the product.  Step 3 above includes mock-ups, which can be used to validate with customers – but Werner’s post doesn’t mention validation or user testing.

My belief is that the Amazon approach can be coupled with lean startup principles in a couple of ways:

1. Take the press-release, work it into a simple marketing site, with some kind of “Coming Soon” and the opportunity to leave an email address.  This allows you to see if the product resonates with potential customers.  Some startups use this approach.  It can help to identify duds – products with almost 0 interest – but it’s harder to know how to interpret some interest.
   
2. Validate the customer experience that is being developed in step 3.  Get out of the building, find some potential customers and see if they are excited about this product, and would find it usable and valuable.
3. Save the FAQ and User Docs until you’ve validated the product.  Once validation is complete I could see how the FAQ and User Docs could form the rest of the product specification for engineering – relieving you from creating detailed product requirement docs that will eventually get thrown away (the FAQ and User Docs can serve as requirements and can have value for customers).

Overall an interesting concept and something to try when pursuing a new product.