This blog post discusses my experience as an executive at Amazon, highlighting the importance of mechanisms and leadership principles in business success. I emphasize the significance of having a defined framework to maintain focus and make progress, drawing on my own experience at Amazon Web Services. I explore utilization of these strategies in managing your own company.
"The working backward process is a huge amount of work. But it will save you even more work later" - Jeff Bezos.
Welcome to the first in a series of Blog posts on my experience working as an executive at Amazon.
With almost three decades of experience in the hi-tech industry, I have gained tremendous knowledge on how to build, market,and monetize software. From floppy discs to SaaS (Software as a Service) - mycareer has taken me through so many game-changing companies that I can't list them all! When I joined Amazon for the first time, however, little did I know what an invaluable learning journey was ahead of me, transforming my whole perspective regarding business formation and product definition management.
In my five-year term as General Manager at Amazon Web Services (AWS), I was reminded that acquiring knowledge is always possible, and even the most experienced can still learn new things. One of the big lessons I took from this experience were the significance of mechanisms and leadership principles.
Mechanisms are systems or techniques setup to manage a business, while leadership principles serve as guiding values to help you make informed decisions. Both play an essential role in any company but are especially important for startups looking to get off the ground quickly. Having a defined framework is critical to maintaining focus and making progress. Without mechanisms that provide structure and guidance, you can quickly get overwhelmed by the details and lose track of your goals - resulting in wasted time. That's why relying on these processes helps you stay productive and reach success faster!
Without a solid set of mechanisms, company's flounder with "good intentions". This is at the center of Jeff Bezos' mindset around ownership and accountability.
"The road to hell is paved with good intentions" - Anonymous
There is difference between what someone intends to do and what they actually do. In other words, the road to failure is made easier by good intentions. A good intention, will always remain a good intention, unless it has mechanisms to drive execution.
Even after departing from Amazon, I still utilize these same effective strategies when managing my own companies and advising customers - testimony of its potency no matter what side of the business you're on! Of all the things I learned there. However, the working backward mechanism has stayed core to my perspective as a Product Leader today. In particular, the PRFAQ process.
Amazon has based its culture and business approach on two main components. These are a set of leadership principles, which can be found on their website, and five specific mechanisms or processes that they use to operate effectively. This Blog post is focused on #4.
1. The Bar Raiser process is a hiring method that guarantees Amazon employs high-caliber individuals compatible with its leadership principles.
2. The Single Threaded Leadership model enables Amazon to enter and excel in new markets through a decentralized organizational design.
3. The 6-Pager Narrative is a tool used in company meetings as an alternative to Powerpoint. It helps leaders to understand better, summarize, and assess complicated information. Furthermore,it helps Bezos to stay informed about the entire decentralized company.
4. The process of Working Backwards involves teams drafting a press release and FAQ before initiating a project. This enables the company to evaluate and choose the most effective ideas.
5. Amazon's method for handling Input and Output metrics, including how they measure, analyze, and implement them in the company.
A few books have been written on the Amazon approach to running businesses. Still, my favorite one is by Bill Carr, and Colin Bryar, called "Working Backwards: Insights, Stories, and Secrets from Inside Amazon."
Product teams need a solid approach to producing new product ideas from the Customer's viewpoint, and PR/FAQs provide that. This strategy necessitates articulating things clearly for the desired target audience: identifying them, recognizing the issue or demand they have, illustrating how your solution resolves this problem or meets their need, then persuading them why selecting your resolution is best.
Before your team gets too invested in their designs and plans, it is imperative to consider the Customer's experience with the product. This includes understanding why they may use or buy it and any potential issues that could arise. Writing press releases and FAQs before coding begins, setting budgets, or allocating personnel helps identify the features worth investing in for maximum success.
Although this method may harm product development timelines, it often saves time and money. I once attended a company all-hands meeting at Amazon where an employee asked Jeff Bezos a question as to whether Working Backwards is necessary or if it is simply too laborious.
If you have ever been curious about his response, the video went viral on YouTube. Here's a link to Jeff's talk on the PRFAQ at a company all-hands meeting.
We begin the process of Working Backward with five questions.
1. Who is the Customer? - consider the time, place, and situation
2. What is the Customer's problem or opportunity? - specify a problem you are trying to solve, and define the size of the problem.
3. What is the most critical Customer benefit? - prioritize what the customer values.
4. How do you know what customers want or need? - Recognize that your personal experiences may not be representative of customers. Challenge yourself to use data to back your thinking.
5. What does the Customer experience look like? - Whiteboard sketch, Storyboard, User journey map, Wireframe, Technical architecture diagram
1. Working Backward prioritizes the customer experience, which allows you to gain a deeper understanding of your customer’s needs and make decisions that exceed their expectations. On the other hand, a skills-forward approach cannot deliver this benefit.
2. When utilizing Working Backwards as your process, it may feel like going slow initially to move faster later; however, taking time at first will help ensure maximum velocity by confirming that your goals are correctly set for success!
3. Crafting a PR/FAQ document demands discipline, which may take several days or weeks to finish. To ensure that your material is up-to-par before the Working Backwards meeting, solicit feedback on drafts from other people early and often. Exercise patience: you will require multiple revisions before declaring the work finished.
4. Incorporate your leadership principles into daily tasks - Working Backwards is a fitting example of integrating one or more of the company's leadership values into everyday procedures. Whether you accept it or not, this process is an excellent illustration of such incorporation.
Writing the PR/FAQ is only the initial hurdle. You must then endure a long and complicated review procedure with your stakeholders and leadership team to ensure it meets their expectations.
As part of the review process, Amazon holds a 'Narrative' meeting with stakeholders to provide thorough feedback for over an hour. At this session, attendees are asked to read product development documents such as PR/FAQs before offering their opinion on improvements that can be made. By engaging in this meticulous review practice, we ensure that only the highest-quality results come from our products and services.
Narrative meetings are divided into two distinct segments.
1. Silent reading (20 min); At the beginning of every meeting at Amazon, everyone is granted a 20-minute window for silently perusing through the 6-page PR/FAQ. This practice has been purposefully designed to ensure that all attendees read the document with the utmost attention and that they view one uniform version (including any recent updates). After some investigation, we discovered that people need around three minutes to browse each page - hence why this time was allocated!
2. Discussion (40 min); This part of the session is vital, where we seek valuable feedback and invite challenging queries. If the PR needs to be more precise to make someone want to purchase our product/service, it must be rewritten and submitted again. Similarly, if any inquiries have yet to be answered or new ones are found, they must also be addressed adequately.
The primary purpose of the PRFAQ meeting is to leave with a clear idea of what we want customers to experience and the rationale behind it. Working together as a team, we always searched for truths to assess whether the concept should be further investigated or set aside. When leaving the meeting, everyone should understand why building something matters before acting on it.
This approach was refreshing as someone who had come from a corporate Powerpoint culture. In Powerpoint culture, the employee is "on show" and must "present" to the team or executives making decisions. It was the ultimate in corporate showmanship. At Amazon, I remember one executive saying to someone on my team, "You don't need to present to me. I'm going to read your PRFAQ, ask you some questions, and then you can leave the room," And he meant it most sincerely and humorously!
The PR/FAQ under consideration was always carefully crafted and presented to the leadership multiple times for it to become a reality. Doing so ensures that any gaps in understanding are filled, making successful implementation possible. If the advantages mentioned are not attractive to customers, the Total Addressable Market must be more significant. It might be time for product managers and authors to return to the drawing board. Iterating on a press release may cost less than making changes directly in products - so why not try it? We were encouraged to keep revising until we produced convincing benefits that would capture our audience's attention!
During my time with Amazon, I noticed that many PR/FAQs still need to make it to the point of becoming actual products, including many of my own! This is likely because too many product ideas are vying for resources and capital amongst hundreds of potential projects product managers pitch each year. With such intense competition, only a select few make it through the pipeline to become successful products.
The cream of the crop will always pass through and be given priority in allocating capital, regardless if it originates from a large corporation like Amazon or an investor. Rejecting most potential products may seem counterintuitive, but this is beneficial for businesses; Taking time to consider every detail upfront can save companies resources that would have been spent on constructing something with minimal impact - thus conserving their energy to build those items which are likely to produce maximum customer satisfaction and business gains.
I have encountered a few common questions while talking with clients about the PRFAQ process, especially from those indoctrinated into the corporate Powerpoint stage show. I have heard a variety of responses. For instance:
"For larger businesses, the PR/FAQ is an invaluable tool for success; however, it only guarantees results in some scenarios, right?"
"The PR/FAQ functions best with more straightforward solutions with fewer risks and uncertainties associated with them; more challenging problems require different navigational strategies to resolve the issue at hand successfully"
"Since iteration can change target customers, goals, or opportunities, why bother writing up a lengthy PR/FAQ if it is only subject to repeated amendments"
However, I have never found these justifications to be all that convincing. For example, Amazon's PR/FAQ process was created to tackle the difficulties of product innovation, which remain the same whether you work for a major company or a smaller one (overlook internal politics). In both cases, you must concentrate on adjusting amid enormous uncertainty; it only makes a little difference if this is done within the confines of an expansive corporation or small business.
Now, as for the second objection? Is your startup concept more intricate than developing the Kindle from absolute zero? Can you profess a less risk-ridden plan than when cloud computing was first conceptualized? And if we flip this concern around, is it even better if you decided to make explicit customer value assumptions with each new iteration of your process instead of leaving them out entirely?
Contrary to widespread belief, you can iterate with a PR/FAQ. Admittedly, your initial customer assumption or solution might need to be corrected; however, you must create and revise a PR/FAQ for each iteration process.
Crafting a PR/FAQ can be an uncomfortable experience, yet it is helpful because it serves as a form of signaling. If you need help to answer the five critical questions associated with the document, this often indicates that more work needs to be done beforehand - and quickly! Do not wait until after all your hard work has been completed; address these issues now so you do not feel overwhelmed later.
Indeed, stumbling upon a working solution without purposeful direction is feasible. Yet let us be honest with ourselves: Relying on luck is not a sound approach. Let us aspire for something greater than randomly flailing until we get lucky!
When I first began this journey, the biggest concern on my mind was: "How do you make continual improvements using a PR/FAQ?" When creating something new and unique, you only know what to build or who it is for much later; it is usually determined through trial and error. What role does the PR/FAQ have in this process?
When I first attempted to write PR/FAQs for an AWS (Amazon Web Services) service in 2017, my results were far from successful. Initially, I wanted to satisfy various customer needs with limited development resources that needed fixing. After realizing this mistake, I adjusted accordingly and saw much better success the second time around. Once I zeroed in on a specific target audience, it became apparent to me that I had not invested enough time conversing with potential customers—verifying this was the fact that I didn't even know what solution they wanted! Thus, making it impossible for me to create content.
Being a product-builder, I felt compelled to create a prototype and check whether something powerful would be made. Even though the iteration provided me with some user experience insight, I still needed to determine if this project would be helpful. Although my iteration was not conducted in a strictly organized fashion, and I needed clear objectives, I knew full well that the method behind this cycle of iterating was one of trial and error. My two earlier attempts at producing PRs/FAQs demonstrated to me explicitly that there were still many unknown variables regarding who exactly I was making it all for and which "head on fire" problem truly needed solving. This pushed me to recognize how much it mattered to generate distinct types of new data - even if that eventually ended up being a waste of an entire iteration cycle.
Despite this, I still attempted to craft a PR/FAQ for an unrelated product. After taking the advice of answering five questions thoughtfully, my team and I spent six weeks interviewing thirty current customers. The result was fantastic. Writing a PR/FAQ made creating and launching my new product much smoother. Not only did this enable me to gain clarity on my target audience and desired results, but it also helped me effectively reposition myself in the market. In the end, rewriting how I presented myself internally and externally allowed for a more straightforward execution with a better focus on what mattered most: success!
As I crafted these documents, it became evident that my methods were straightforward: after finishing each PR/FAQ, I immediately moved on to the execution; there was no need for me to pen varied revisions or extra PR/FAQs concerning a single project (such as what Amazon did with the Kindle and AWS). If you are wondering how to approach successive iterations of a PR/FAQ project, do not worry - writing full PR/FAQs for each one is unnecessary. Sometimes, writing the press release might suffice, while only an FAQ will do in others. As Amazon set out to determine S3's failure modes, it drafted a primarily FAQ-based document; when choosing its pricing model, most of its work was devoted solely to crafting a press release.
There is no need to generate a full press release for every evolution of an ongoing project. For example, when the Kindle team stumbled upon their sought-after e-ink display, they only developed a technical FAQ instead of another PR - it would have been ludicrous for them to update their main PR/FAQ each time they made technological decisions.
None of us were (for obvious reasons) permitted to take actual documents with us when we left the company. However, I have produced this document as a guide for crafting PR/FAQs and running Narrative meetings to fully prepare you for each new product launch or business proposal.
Here is how:
1. To get started, duplicate this document if you have not already done so: Duplicate now
2. Develop the write-ups - Right in this doc, craft future-oriented PR/FAQ documents
3. Lead the meeting - Schedule a sixty-minute 'live' review and discussion session with contributors from various functional areas
Ultimately, my motivation behind this blog is to help to unlock the secrets of working backward at Amazon. Working there was an enriching experience, and I will always advocate against Powerpoint presentations! Try PR/FAQs with your team!
