amazon working backwards process

Amazon has been using “working backwards” widely for decades. What they do is to work backwards from the customer, instead of starting from an idea for a product and then getting customers to adopt it. Sounds familiar? (Hint: correlate with my post on growth product management!) Working backwards can be applied to any product decision – but it’s most effective when developing new products and features. 
 
To put it simply, 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 direct 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.
 
The product team will keep iterating on the press release until they’ve come up with benefits that are actually benefits – in other words, if the benefits listed aren’t exciting to customers, then most likely they should not be built.
 
Here's an example outline for the original amazon-working-backwards-press release:
​

• Heading - Names the product in a way the reader (i.e. target customers) will understand.
• Sub-Heading - Describes who the market for the product is and what benefit they get. One sentence only underneath the title.
• Summary - Gives a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
• Problem - Describes the problem the product solves.
• Solution - Describes how your product elegantly solves the problem.
• Quote - A quote from a company spokesperson.
• How to Get Started - Describes how easy it is to get started.
• Customer Quote - Provides a quote from a hypothetical customer that describes how they experienced the benefit.
• Closing and Call to Action - Wraps it up and give pointers where the reader should go next.

 
Keep it simple: If the press release is more than a page and a half, it is probably too long – this is not a spec. Teams can accompany the press release with a FAQ that answers all of the other business or execution questions so the press release can stay focused on what the customer gets. 
 
The rule of thumb is that if the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows.
 
Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, "Are we building what is in the press release?" If they find they're spending time building things that aren't in the press release (in other words: over-engineering), they need to ask themselves why. This keeps product development focused on achieving the customer benefits and not building extra fluff that takes longer to build, takes resources to maintain, and doesn't provide real customer benefit.

• Credits: Ian McAllister of Amazon

---

​Let me know what you think! 
DM me @philippemora on IG and Twitter
​My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. 
​
Head of Digital Product
thinker, doer, designer, coder, leader