Working Backwards in Product Management

I just want to bring to spotlight some significant product management contributions buried into huge mass of Internet generated information

Ian McAllister from Amazon could be the most significant hands-on product management guru that I came across. Ian describes the "Going Backwards" a product management creative process, originally published on Quora October 17, 2010.  In my opinion it deserves a Nobel Prize nomination in Product Management (Please don't google it. It is just my admiring metaphor).

There is an approach called "working backwards" that is widely used at Amazon. We try to work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it. While working backwards can be applied to any specific product decision, using this approach is especially important when developing new products or features.

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!).

Here's an example outline for the press release:

• Heading - Name the product in a way the reader (i.e. your target customers) will understand.

• Sub-Heading - Describe who the market for the product is and what benefit they get. One sentence only underneath the title.

• Summary - Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.

• Problem - Describe the problem your product solves.

• Solution - Describe how your product elegantly solves the problem.

• Quote from You - A quote from a spokesperson in your company.

• How to Get Started - Describe how easy it is to get started.

• Customer Quote - Provide a quote from a hypothetical customer that describes how they experienced the benefit.

• Closing and Call to Action - Wrap it up and give pointers where the reader should go next.

If the press release is more than a page and a half, it is probably too long. Keep it simple. 3-4 sentences for most paragraphs. Cut out the fat. Don't make it into a spec. You 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. My 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. 

Oh, and I also like to write press-releases in what I call "Oprah-speak" for mainstream consumer products. Imagine you're sitting on Oprah's couch and have just explained the product to her, and then you listen as she explains it to her audience. That's "Oprah-speak", not "Geek-speak".

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 (overbuilding), they need to ask themselves why. This keeps product development focused on achieving the customer benefits and not building extraneous stuff that takes longer to build, takes resources to maintain, and doesn't provide real customer benefit (at least not enough to warrant inclusion in the press release).

 Ron Brinkmann,  who self describes himself as a "Technology Dilettante" at Amazon, adds another punch:

The 'Working Backwards' methdology couples nicely with another Amazon approach - the fact that powerpoint presentations are strongly discouraged as a way of communicating between different groups in the company.  The thinking is that the success of a verbal presentation is very dependent on the skills of the presenter whereas boiling everything down to a written document takes the 'personality' issue out of the equation.  It's not uncommon to attend meetings at Amazon that begin with everybody sitting in silence for the first 5-10 minutes reading a document.

 I am re-reading the answers on March 15, 2012. This is after Steve Jobs passing away and the publication of his biography. I am amazed how the working-backwards, imaginary-release method shifts the responsibilities of knowing what customers want to the product manager. The anticipation of the customer reaction is predicted by the product team, and not lengthy customer interviews. This is revolutionary indeed and proven right once more in the Steve Jobs contention that customers do not know what they want.

 They complain of symptoms, but they do not know the cure.