Putting Amazon’s PR/FAQ to Practice

Amazon has a fairly famous practice of writing press releases before launching new products. The name they have for this is the ‘Working Backwards process’ and the primary artefact to come out of that process is something called a ‘PR/FAQ’ — so named because the one-page Press Release is usually accompanied by a long FAQ section, covering most, if not all, the commonly asked questions about the proposed product, feature, or initiative.

I last covered the PR/FAQ process in my summary of Colin Bryar and Bill Carr’s Working Backwards, a book about Amazon’s internal practices. I also went deep into the process in Product Development as Iterated Taste, which covered the PR/FAQ in the context of other product development methodologies.

In that latter piece, I quoted Bryar and Carr, who wrote:

The fact that most PR/FAQs don’t get approved is a feature, not a bug. Spending time up front to think through all the details of a product, and to determine—without committing precious software development resources—which products not to build, preserves your company’s resources to build products that will yield the highest impact for customers and your business. (emphasis added)

Another one of the biggest benefits of a written PR/FAQ is that it enables the team to truly understand the specific constraints and problems that would prevent a new product idea from being viable and aligning on them. At that point, the product or leadership team must decide if they will keep working on the product, addressing the problems and constraints surfaced by the PR/FAQ and developing solutions that will potentially make the product viable, or if they will set it aside.

(…) If, after the PR/FAQ process, the leadership team still believes in the product and wants it to become a reality, the process will have given them a thorough understanding of the problems that would need to be solved in order to move forward with it. Perhaps a problem can be solved through an acquisition or a partnership. Perhaps it can be solved with the passage of time — new technologies may become available, or the costs of the technology might come down. Perhaps the company decides that the problem or constraint is solvable, that the solution will require risk and cost, and that they are willing to assume that risk and cost because the TAM is large and therefore the potential rewards are great.

The way I understand it, Amazon’s PR/FAQ process does a number of things:

1. It forces the execution team to grapple with the proposed customer value, from the perspective of the customer.
2. It makes it very clear what the purpose and scope of the proposed experiment is. (Every product launch, intended feature, or proposed internal initiative is an experiment to some degree, whether you like it or not.)
3. It becomes a syncing mechanism for various stakeholders to gain conviction together, before putting too much capital at risk.
4. It allows leadership to keep abreast on a large number of new product iterations and initiatives, at a sufficient level of clarity and detail.

I think all of these things are fairly easy to glean, just from reading the (many) descriptions of PR/FAQs you may find on the internet. But what do these things actually feel like, when you put them to practice?

I’ve spent the past nine months attempting to apply Amazon’s PR/FAQ to my context, and after a number of frustrating, failed attempts, I’ve finally gotten it to work. My goal here is to write up some notes from practice. Some of these things are not obvious, and my take is that many public descriptions of the PR/FAQ make it seem relatively easy to write — perhaps because the people writing them are former Amazonians (who’ve had some practice inside the company and are therefore not novices).

This essay will cover the PR/FAQ from the perspective of a novice. I have attempted to adapt the process to a single team context — and by ‘single team’ I mean a tiny group: myself and at most two other people. I’ll talk about what I found difficult about the approach, what I found surprising, and what I’ve found valuable now that I’ve gotten it to work.

For full disclosure, I’ve had one small advantage: about six months ago, I started working on a project with Colin Bryar and Bill Carr — the same authors of Working Backwards. I won’t talk about that project for now, but my more recent attempts have been coloured by the work I’ve done for them.

(It turns out that if you want to apply a process to your context, it’s really helpful if you have access to someone who was there when that process was first invented.)

Any differentiated insight here is attributable to Colin Bryar (who I’ve had the most contact with); any mistakes in interpretation are mine alone.

The Five Questions

I’ve covered the format of the PR/FAQ elsewhere. The basic idea is that it consists of:

• A 1-page press release.
• An internal FAQ, which addresses questions that internal stakeholders might ask (e.g. what’s the estimated bill of materials for manufacturing this widget?)
• An external FAQ, which addresses questions that customers and other external stakeholders might ask (e.g. would Whispernet be available in all regions at launch?)

According to Bryar, there are really five questions that you’ll want to answer in a typical Amazon-style PR/FAQ. Most of these questions should be answered in the 1-page PR, with the exception of the final one:

1. Who is the customer?
2. What’s the problem you’re trying to solve?
3. What’s the solution (and you need to explain to the customer, not to yourself).
4. Would they reasonably adopt this solution, because you’re asking for a behaviour change?
5. What’s the Total Addressable Market (TAM), and is it big enough to be worth doing?

In practice, Question 5 is most often covered in the FAQ. The way this works is that as you refine your product and solution, the TAM changes. Typically, the FAQ portion addresses the assumptions you're making, and then the group seeks the truth around those assumptions. So it makes sense to address the TAM in the FAQ.

I’d like to draw your attention to a few other things.

First, these questions are guidelines, not an ordered checklist. Actual PR/FAQs read like proper press releases that just happen to answer all five questions (even if implicitly).

Second, in a small business context you don’t necessarily have to answer Question 5 — you aren’t operating a multi-billion dollar company, after all. I find myself replacing it with an equivalent “is this worth doing?”-type question, which in my case tends to be “do the pros outweigh the initial and ongoing time costs?” You’ll probably have a better question for your context; caveat emptor.

The third and final thing you should notice about the five questions is that it assumes you’ve figured out who the customer is. This sounds trivial, but it really isn’t. In the early days of a new product or feature or service offering, it’s often not clear what you’re building, much less who the customer is. To make things worse, your initial idea of the customer is often mistaken.

What this means is that the PR/FAQ is a very unforgiving method of forcing you to think about your potential customer. This is what makes it so useful, but also what makes it so difficult to do.

The Most Difficult Aspect of Writing a PR/FAQ

The most difficult aspect of writing a PR/FAQ is emotional.

If you find yourself attempting do a PR/FAQ, it’s likely that you’re writing to concretise some new idea you have in your head. The dominant feeling that you’ll experience when you attempt to write one is that you will discover just how shitty your new idea really is.

It is very uncomfortable to have your idea ripped to shreds in front of you. The fact that this is built into a writing process makes it all the more remarkable — normally, you’d need someone else to help call you out on your bullshit. Writing a press release from the perspective of a consumer front-loads the discomfort: who is this for, really? Why would they even care?

I’m convinced that customer-centricity is the main benefit of the PR/FAQ. Sure, you may accomplish many of the same goals with a more conventional Product Requirements Document (PRD). Or you may write a free-form, technical spec — which was what I commonly did in previous roles. But I’ve learnt that the ‘press release’ portion of the PR/FAQ format ruthlessly forces you to reason from the perspective of a customer — especially one who does not give a shit about your buzzwords, your technology stack, or whatever other sweet lie you tell yourself that makes your idea a good one. The harsh reality of product development is that customers don’t care about what you’re building; customers care only about how your product makes their lives better. And there is nothing more fiercely constraining towards that end than a one-page press release.

So what do you do in the face of that discomfort? Most people will react in one of two ways:

1. You power through your feelings of shittiness, with the knowledge that it’s better to deal with the ugly truths up front.
2. You come up with some reason to discredit the PR/FAQ process, so you may avoid dealing with the powerful negative emotions you experience.

I’ve heard a variety of justifications on that second point. For instance:

1. “Amazon is a large company, and the PR/FAQ only works in large companies.”
2. “The PR/FAQ only works for simpler ideas with a lower amount of uncertainty; it doesn’t work for ideas that require more wicked navigating of the Idea Maze.”
3. “The PR/FAQ does not take into account iteration. Sometimes your target customer or target problem changes as you execute and react to new information. Sometimes new opportunities present themselves that can’t be predicted at the outset. Why should you write a PR/FAQ if you’re going to iterate anyway?”

But these justifications have always rung a little hollow to me. For instance:

• Amazon developed the PR/FAQ process to deal with new product development, and the primary challenges of new product development are the same in a large company vs a small company (if we ignore internal politics, that is). In both scenarios, you’re dealing with iteration under massive uncertainty; whether you do this in your perch at a large company or in a small company is mostly irrelevant to the thorniest challenges at hand.
• As for the second objection … really? Is your startup idea more complex than developing the Kindle from scratch? Is your startup idea more uncertain than inventing cloud computing? And, to flip this objection on its head, is it really better to run your process without making your assumptions about customer value explicit during each iteration?
• Finally, it’s simply not true that you cannot iterate with a PR/FAQ. Yes, you may be mistaken about your initial customer or you may get your initial solution wrong, but that doesn’t preclude writing a PR/FAQ ahead of each iteration. We’ll talk more about this in a bit.

One useful way to reason about the discomfort in writing a PR/FAQ is that it serves as a signalling mechanism: if you feel like you’re pulling teeth while writing it, it means that you’ve not done the work necessary to answer the five questions in a plausible manner. It also means you should probably go out and get that information — you don’t get a free pass here; these are things that you’ll need to figure out sooner rather than later. And better sooner rather than later; you don’t want to grapple with these things after you’ve built a ton of shit.

Finally, sure, ok — it’s totally possible to blindly iterate your way to a solution that works. But let’s not kid ourselves, shall we? Getting lucky is not a coherent strategy. We should aim to do better than “flail around until we get lucky”.

Iterating with a PR/FAQ

The biggest question I had when I started on this process was: “How do you iterate using a PR/FAQ?” After all, you often do not know what to build or who to build for in the earliest stages of a new product; you tend to figure out by trial and error. How does the PR/FAQ play into this?

I started writing PR/FAQs for an app I was building in Q4 of 2021. My first few attempts were abject failures. In my very first stab I was confronted with the fact that I simply wanted to serve too many different use cases for too many different customers. This was unrealistic; I had limited development resources. When I then decided to zoom in on a particular subsegment, it became clear to me that I’d not spent enough time talking to potential customers — and the proof of this was that I simply didn’t know what solution appealed to them (and therefore couldn’t write it up!)

I then did what every dumb software founder does: I went, “ok, let me build a prototype to see if there is something compelling here”. This burnt a few months of my time.

Was this useful? I’m leaning towards ‘no’, though I’m not entirely sure — the iteration generated some user experience information, though I’d be lying if I said it was all useful. But notice what I’m not saying: I’m not saying that the iteration was a disciplined one, nor that I had a crisp plan for this particular iteration cycle. I’m saying that I did it in the full knowledge that I was doing something blind! The two earlier PR/FAQ attempts had made it very clear to me that I didn’t have the foggiest who I was building for, nor what ‘head-on-fire’ problem I was trying to solve. It pushed me to understand that I was taking action simply to generate random new information — and that it could well be a waste of an iteration cycle. In other words, it confronted me with my own builder bullshit; it prevented me from lying to myself.

(But it didn’t prevent me from doing the iteration in the first place — some lessons are learnt the hard way. Also, did I mention this was an abject failure? Well, yeah.)

A couple of months later, I took another stab at writing a PR/FAQ, albeit for the Commoncog site relaunch. This time, I took the idea of answering the five questions seriously — I hired Audrey Liu on a part-time basis (we’d worked on a similar project before), and together we did a month-long interview process with existing Commoncog members.

I found the resulting PR/FAQ much easier to write. Consequently, the execution on the new Commoncog site design, along with the copywriting and the overall repositioning, went very smoothly — I knew exactly who I was targeting, and what outcomes I wanted to achieve.

I then repeated it with the Commoncog case library alpha, and finally the case library beta test. I’ve attached a copy of the beta’s PR/FAQ below.

As I created these documents, though, I started noticing that my attempts were relatively simple: I finished each PR/FAQ and dove straight into execution; I never had to write radically different revisions or even follow-up PR/FAQs for aspects of a single project (as, say, Amazon did for the Kindle and for AWS).

So how should you iterate on multiple PR/FAQs within a single project?

At some point I put this question to Colin, and he explained that you don’t have to write full PR/FAQs for each iteration of a project: for some iterations you could just write the press release, and for others you could just do the FAQ. So, for instance, when they were working out AWS S3’s failure modes they wrote a document that was mostly FAQ; when they were working out S3’s pricing model it was mostly a press release.

This made more sense to me — I always thought it weird that we had to do a full press release for every new iteration of an ongoing project. I now imagine that when the Kindle team discovered an e-ink display that worked, the resulting PR/FAQ was mostly a technical FAQ more than a PR; for some reason I thought that the poor Kindle team had to update their primary PR/FAQ each time they made a new tech decision.

I was very happy to hear that this wasn’t the case.

Colin Adds

I asked Colin for his thoughts, and he has this to add:

I think it's a bit more nuanced than this.

It's not a case of should I:

• Write a PR and FAQ
• Just write a PR or
• Just write an FAQ.

In the early stages of an idea when you are struggling to answer questions 1-4, you could start just by writing a PR (or multiple competing PR with different variations). Then you typically write both the PR and FAQ. For complicated products or services, you may need to dive deep on one specific aspect. In that case, your document doesn't need to cover ground that was already debated and settled. And for some ideas, you may need two sets of PR/FAQ documents. A marketplace with sellers and buyers is a great example here. Since you are talking directly to the customer when you have more than one set of customers, you may need more than one set of documents.

Don't let the process drive you. You should use the process in a way that helps you solve the problems you are currently facing.

A Sample PR/FAQ

I’ve included the PR/FAQ I wrote for the Commoncog Case Library Beta below, so you’ll have an example of a PR/FAQ.  I used this document to gain alignment across four different people.

For the final product, see here.

Note: I highly, highly recommend the following template from Working Backwards. As you’ll see below, I follow it quite faithfully.

PR Newswire Singapore, 2 August 2022
Postcognito Pte Ltd Announces Launch of a Public Beta Test of the Commoncog Case Library
The Commoncog Case Library — A new way to accelerate business expertise.

Today, Postcognito Pte. Ltd. announced the launch of a public Beta Test of the Commoncog Case Library (CCL), targeted towards business operators interested in accelerating their business expertise.

Expertise in business requires some understanding of how frameworks and concepts instantiate in the real world. Typically, competent operators expand their understanding of such concepts through lived experience, or by reading case studies, books, news articles and other information sources. However, searching for such concept instantiations across the entire universe of content is daunting. Many operators do not have the time necessary to consume such source material, given the demanding nature of their working lives.

The CCL solves this problem by curating a sufficiently large selection of cases for each business concept. Each case is concise: no more than 2000 words for most cases. The cases are written to a high standard of quality and a high degree of nuance. Each case will come with a full complement of sources, which readers may use to dive deep if they so wish.

For this beta test, readers will be offered access to a series of seven cases built around one concept: ‘The Idea Maze’. Readers will get a short introduction to Cognitive Flexibility Theory (CFT) — the underlying cognitive science theory that underpins the CCL — and receive all seven cases via email. They will get to choose between two different types of email frequencies: once a day, or three times a week. Alternatively, they may opt to read all seven cases on the Commoncog website, at their own pace.

Each case in the CCL Beta will come with a separate forum thread attached. Members will be able to comment on each case, while non-members will be allowed to read comments.

When the email series is complete, readers will receive a final essay that summarises the similarities and differences of the seven cases, per CFT methods. Participants will then be asked to fill out a short, 60-second survey that queries them about their experiences with the Beta Test.

“The launch of the Beta Test allows participants to get first-hand experience of a CFT hypertext learning library.” says Cedric Chin, founder of Commoncog. “We hope business operators who go through the Test will have a better understanding of our chosen concept. More importantly, we hope they will internalise the notion that business frameworks are only useful if you understand all the ways they instantiate in the real world.”

“The CCL Beta was very enjoyable. It was also educational — I have a better appreciation of the difficulties companies have experienced in launching new products. I sent the cases to my team, as we are currently attempting to launch a new product at our company. The cases reassured us that what we are doing and experiencing is not unique, given the extreme uncertainty we face at work.” says Paige Lee, Product Manager at XYZ Technologies.

External FAQ

Q: Will this Beta Test of the CCL be free forever?
A: No, the beta test will be free for a limited period.

Q: Will a non-member get access to the forum for the Beta Test?
A: No, only members will get full (read+write) access to the forum. However, Beta Test forum threads will be made publicly available for non-members to read.

Q: How is the CCL different from paid book summary websites like getAbstract, Blinkist and Shortform?
A: Like paid book summary websites, the CCL does summarise certain books for its cases. Unlike book summary services, the CCL is organised around business concepts, and is written to accelerate business expertise for its members. Additionally, the CCL is not limited to summarising books — it draws from a wide variety of sources, which can range from multi-hour podcasts to Form 10-Ks.

Q: Why should I pay for a Commoncog membership to access the CCL when other book summaries are free, like Four Minute Books?
A: CCL is written with the explicit goal of accelerating business expertise. Book summaries are not written with this intention in mind. They are not organised around business concepts, and are not written to highlight these business concepts nor show how they instantiate in the real world with all its nuances.

Q: If I join now as a new member, when can I expect the CCL to expand and to what size?
A: The CCL will expand for as long as is feasibly possible.

Q: How do I know that CFT works?
A: We expect you to reach for fragments of the cases you’ve read when you encounter a similar business tactical or strategic situation in your own life.

Q: How does the Idea Maze concept relate to me? It’s not like I’m not going to launch the next Instagram.
A: The Idea Maze concept will be relevant to you if you are starting a new company or starting a new business unit or product line within your company. This second set of experiences is more common amongst the broader population. Exposure to the Idea Maze concept should help ground you, so you know what to expect.

Q: As a paid member, why are you making the CCL free?
A: We want to expose the CCL format to more participants, in order to generate better feedback for the end-product. We will use what we learn here in finalising the actual CCL, which is reserved for members.

Internal FAQ

Q: What are your goals and success criteria for the Beta Test?
A: Two goals:

1. We expect that the essay at the end of the sequence will make the experience more attractive. We’re aiming for a Median score of 6/7 on education (higher than 5.5 on the alpha test) while maintaining 6/7 score on entertainment.
2. We hope for at least 500 participants, of which 200 fill in the 60 second exit survey, and we get at least 10 people who fit into 1 of 3 buckets that we can reach out and have a 30 minute conversation with. Intend to ask them ‘willingness to pay’ questions during that call in order to get a feel for pricing.

Q: How are you going to publicise the Beta Test?
A: Through the Commonplace newsletter, a link to the Beta Test landing page on Commoncog’s homepage, Twitter, and LinkedIn.

Q: What would the Beta Test look like? Would it run on custom software or would it just be email?
A: The Beta Test would run on ConvertKit where readers get to sign up for different sequences based on their frequency of emails. It would also be launched on the Commoncog website, through some hacked together template modifications.

Q: Would subscribers to the Beta Test be automatically enrolled to the Commonplace newsletter?
A: Yes they will, at the end of the beta test, unless they are already subscribed to Commonplace. They may opt out any time from the Commonplace newsletter.

Originally published 08 September 2022, last updated 15 October 2023.