Starting from the customer experience to build products customers love
Today we are talking about the “working backwards” approach to product that was created at Amazon.
To give us the details on this approach, Colin Bryar is with us. He joined Amazon in 1998—four years after its founding—and spent the next 12 years as part of Amazon’s senior leadership team. For two of his years at Amazon, Colin was Chief of Staff to Jeff Bezos, AKA “Jeff’s shadow,” during which he spent each day attending meetings, traveling with, and discussing business and life with Jeff. Colin is co-founder of Working Backwards where he coaches executives at both large and early-stage companies on how to implement the management practices developed at Amazon. He is also the co-author of Working Backwards: Insights, Stories, and Secrets from Inside Amazon.
Summary of some concepts discussed for product managers
[2:07] Where did “working backwards” originate?
Working Backwards started at Amazon in the early 2000s. We were trying to figure out how we were going to move into the digital space. Amazon’s first leadership principle is customer obsession, and we realized we weren’t as customer-obsessed as we needed to be. Jeff Bezos wanted to create a new type of process to make sure that the customer was with us for the very beginning of an idea all the way through the journey to when the product was released. And we had tried a bunch of standard tools to build products, but we realized that the one person who wasn’t in the room was the customer, and that was the most important person to have with us on the journey.
We created a process called Working Backwards, which is starting from the customer experience and then working backwards from that to build a new product.
[4:39] What is the “working backwards” approach?
The primary tool that we use is the PRFAQ document, short for press release and frequently asked questions. When someone has an idea for a product or service, the first thing they do is write a PRFAQ document.
The first part is the press release, which must:
- Be one page or less
- Clearly define who the customer is
- Clearly define the problem you’re trying to solve for that customer
- State your solution
- Convince the customer that this solution is worthy enough for them to change their behavior from the alternatives
- Be in written in language that a customer can understand
- Be written to the customer
After reading that press release, if you’re not excited to go out and buy the product or use the service, go back and rewrite it. It’s an iterative process.
Once you have a press release you’re satisfied with, write the frequently asked questions. Some people break this up into two parts—external FAQs that the customer or press will ask and internal FAQs that you’ll have to answer in order to make the idea a reality.
[8:55] Do you involve the customer in writing the PRFAQ document?
You don’t need to involve the customer necessarily, but you do need to figure out ways to get the customer needs out in front of everyone in the group. Look at data about how people are currently using your product or service. The best way to understand the customer experience is really to deeply immerse yourself in the data and the problem at hand and come up with conviction that this is a solution to a real customer problem. Then you can do some surveys and focus groups to validate or disprove that hypothesis.
When you’re writing the PRFAQ document, typically a product manager takes the lead. You can’t write it overnight. Allocate an appropriate amount of time to do it. It’s best to show people drafts of the document before you bring it to the leadership. They’ll help refine the idea and make it better.
[12:02] How long are the FAQs and how do you discuss them with your team?
We try to keep the document to six pages or less for a one-hour meeting. You spend about the first 20 minutes reading the document, and then you have 40 minutes of discussion.
You don’t have to comprehensively cover the whole product in each meeting. Start off with the idea. At the next meeting, narrow down the pricing model, etc.
The body of the document needs to be six pages, and you can have appendices added onto that which can run well over six pages that you can refer to as needed.
[15:50] Why have a meeting about the PRFAQ document?
There are two reasons to have a meeting with the team rather than individually reading the draft. First, people will update the document until the very last minute before the meeting starts. If you read it the night before, you’re reading a draft that has gone a little stale.
Second, during the first 20 minutes of the meeting everyone is guaranteed to read the document. Despite best intentions, things come up, and some people might not be able to read it ahead of time.
[16:52] Who is at the PRFAQ meeting?
The meeting includes the person who is eventually going to write the check. You can invite other people like senior leaders who are involved with the project dependencies. I typically would invite high-judgment individuals because I think that they’ll make the idea better.
The goal isn’t the document itself, and in the early stages, the goal isn’t to get the idea greenlit. It’s to make the idea the best it can be before you start to build it. Anyone who will help you do that can be at the meeting.
These meetings help you go through a large number of ideas and pick the best ones. Often people get invested in their idea and try to sell it. This is no the time to sell your idea. It’s the time to uncover the truth about your idea.
[19:59] Have you found the Working Backwards process helps adjust the culture to focus on the merit of ideas rather?
Yes, that’s inherent in writing a narrative and having a collaborative document where people can enter comments before anyone gets a chance to speak to them. Everyone gets to enter their feedback. Then you cover the feedback and it doesn’t really matter who wrote each question. You figure out things you hadn’t thought about before and think about how to mitigate risks. It doesn’t matter if the person sharing is the CEO of the company or the most junior person in the room.
As you go around and ask questions, we encourage senior leaders and the most senior person to go last. You don’t want to bias the rest of the people or discourage them from disagreeing.
[22:00] When do you get feedback from customers?
By the time you write the PRFAQ, you should already have some data that tells you that the problem you’re solving is a problem with customers. You should already have some pretty clear idea of what the customer experience is, where it’s falling short, which problem this idea is going to solve, and how it fits into the whole customer experience as a whole.
Usually your job is to innovate on behalf of customers, not just ask your customers, what you should do next for them. The more data you get to measure the customer experience, the more insights you have on how to improve that customer experience.
Once you have a solution, if you can get validation from customers in a cheap way, you certainly should.
[24:22] How many meetings do you usually have before the idea is greenlit?
Fewer than half of ideas make it through the Working Backwards process at all.
First of all, I’d say less than half of them make it through the process at all. The answer after any meeting is, “yes, we’re gonna go do it,” “no, we’re not going to do it,” or “no, we’re not ready; we need to go get more information.” That third answer is the most common answer for these meetings. You have to go through it a few times.
For most ideas, you would go through about five meetings. A big project like Kindle would have many more PRFAQs, some of them focused on very specific elements of a service.
Jeff Bezos said you want to make most decisions with about 70% of the information you’d like to have, because if you wait to get a hundred percent, your competitors are going to get there first.
[25:55] What is a product that was created using the Working Backwards approach?
One product that comes to mind is the Kindle product. This started off as we were thinking about what we were going to do in the digital space. We needed a product that would be worthy of reinventing the book, which has been around for hundreds of years. As we wrote the press release, we realized four key elements that the product needed to have:
- New type of screen device that does not cause eye strain
- Vast selection of ebooks
- Not tethered to a device and could download a book in under 60 seconds
- Cheaper than a hardcover book
As we gained alignment, we debated whether the Kindle should be an all-purpose device or just an e-reader device. We eventually settled on just an e-reader because there were too many technology hurdles to overcome. This is an example of truth-seeking rather than selling or convincing yourself that it’s a good idea.
Action Guide: Put the information Colin shared into action now. Click here to download the Action Guide.
- Visit WorkingBackwards.com
- Check out Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“The best way to fail at inventing something is by making it somebody’s part-time job.” – Dave Limp
Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.