Over the last few days, there’s been a lot of discussion online about an approach used by Amazon to develop new products, and it can also apply to major version software releases too.
According to Ian McAllister, General Manager at Amazon, Amazon often takes a “working backwards” approach to developing new products and features.
In his words:
“We work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it.”
So, how does this work in practice?
Well, for new initiatives, a product manager would write an internal press release which would announce the finished product. This would be centred around how it solves a problem for the customer, how current solutions (internal or external) fail, and of course, how the new solution will blow existing solutions out the water.
The idea is that the Product Manager then keeps iterating on the Press Release until they have something which is ready for production.
As McAllister says, “iterating on a press release is a lot less expensive than iterating on a project itself”
What I really like about this approach is how it guards against feature-creep. It’s very easy, when writing software, to be tempted to add new features because they’re a “quick win,” or “low hanging fruit” or because “a competitor has them.”
Writing the Press Release first keeps you honest as a Product Manager, and focuses you on solving for the customer rather than internal stakeholders.
A Template For Your Own Press Release
McAllister was also good enough to share a template that you can use to create your own internal press release:
Sample outline:
Title – Give your product a human name that your target customers will understand. This is a little harder for software development, where version numbers reign supreme, so you might want to think of an internal code name.
A great evocative code name that comes to mind from the recent past is Microsoft’s Project Spartan. Spartan is defined as “showing or characterized by austerity or a lack of comfort or luxury.” Microsoft wanted to demonstrate for its new generation of web browser that it had got past the bloat of Internet Explorer. Perfect.
Sub Head – Who is the market for your product, and what are they going to get out of it?
This is great because it forces you past “DevOps In A Box” style product / feature descriptions, and onto the specific benefit that the end user is going to get out of the product or the feature.
Summary – Sum up the product and a benefit in a few sentences.
For Amazon’s recent Dash Button, this is their copy:
“Dash Button comes with a reusable adhesive and a hook so you can hang, stick, or place it right where you need it. Keep Dash Button handy in the kitchen, bath, laundry, or anywhere you store your favorite products. When you’re running low, simply press Dash Button, and Amazon quickly delivers household favorites so you can skip the last-minute trip to the store.”
I love this paragraph because it introduces an entirely new way of shopping for goods in a way that users can understand (incidentally, think they’re going to be very popular!).
Problem — Describe the problem your product solves.
My standard way of getting to the problem the product solves is the Five Whys technique. The Five Whys are a chain of questions which are designed to dig into the outward symptoms of a user experience problem to uncover the motivations at its root cause.
For instance:
1. Why did Sheryl say the sign up flow was broken?
Because she was trying to sign up a second time?
2. Why did the flow break if she was already signed up?
It’s a bug. We didn’t have a test case for it?
3. Why didn’t we have a test case for it?
I just didn’t think of it.
4. Why didn’t you think of it?
The story seemed easy – I guess I didn’t think it through.
5. Why didn’t you think it through?
I guess I was working alone and in a hurry.
You can see how we got very quickly from the root cause to the surface problem – in this case, lack of time for developers – with very little preparation. Do this with your own release, and get to the problem that you are solving for the customer.
Solution – Having done this, describe how you solve the problem for the customer.
Quote from You – Give a quote from a spokesperson in your company.
This will give you practice in writing an “elevator pitch” for your product which you can talk about with stakeholders and customers.
How to Get Started – When will the solution be available? Where can I find a “Hello World” example for this new widget? What’s the sign up flow for the new feature?
Quote from a Customer – Give a quote from one of your customers (hypothetical of course), which explains how they came to experience the new benefit.
Closing and Call to Action – Time to wrap up now, and give the customer some pointers on what they should do next.
Press Release Best Practices
McAllister gave some useful advice
- Keep the Press Release simple – it’s a press release, not a PRD!
- Use 3-4 sentences for most paragraphs
- This is not a spec. Repeat, this is not a spec.
- Accompany it with an FAQ.
- Don’t use geek speak or jargon. So many IT professionals kid themselves that fellow IT professionals find jargon reassuring. Trust me, they don’t.
As a sign off, McAllister said:
“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. ”
What do you think? Have you ever tried to develop a feature this way?