Putting Amazon’s PR/FAQ to Practice - Commoncog

Blog Comments
1

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, of the commonly asked questions about the proposed product, feature, or initiative.

This is a companion discussion topic for the original entry at https://commoncog.com/putting-amazons-pr-faq-to-practice/
1 Like
2

This was a Twitter thread before it was an essay, and the Twitter thread is available here:

4

I’m working on one of these for a product on my team that faces in store associates but also impacts customers to our stores. The primary benefit is for the store associates, so I think writing it as an “internal” press release makes the most sense. Does that fit within what you know about writing these @cedric?

1 Like
5

Yes, absolutely. Amazon has been known to write PR/FAQs for internal services, hell, they’ve also been known to write FAQs (without the PR piece) for certain simpler internal services.

Do keep in mind there’s a template for this. From some quick googling, this seems like a pretty decent resource: Strategy Tool: Amazon’s PR/FAQ. A practical guide with two easy to use… | by Wendy-Lynn McClean | intrico.io | Medium

1 Like
6

Thanks! I already found this incredible resource that I’m using, called something like FamiliarGear, or some name like that? :slightly_smiling_face:

1 Like
7

Hah! Made me chuckle, you did. :slight_smile:

Actually I linked to the template resource because I didn’t highlight the fact that there is a template in this piece, so imagine my surprise when I read a sample PR/FAQ that a friend wrote for his startup, only to realise he had left out whole chunks (like a sample quote from a customer). Then I realised I should’ve been more clear — most Amazon PR/FAQs actually follow a fairly strict template, at least for the ‘PR’ portion.

Good luck with your attempt! I hope it goes well!

8

Just a quick question I wanna jot down and ask for everyone’s inputs. How do you reconcile the relationships between PR/FAQ (Working Backwards) and Effectuation - the process by which entrepreneurs make decisions.

It seems, on the surface, that these two approaches oppose each other? cc @cedric

1 Like
9

Caveat: my understanding of this is built around talking to Colin about these questions.

People often talk about Bezos being ‘relentless’ and ‘wanting to get things done yesterday’. They talk less about his role as ‘chief slowdown officer’ — a name he gave himself.

I believe that you can see this with lower skilled vs more skilled entrepreneurs. Lower skilled entrepreneurs are a frenzy of activity, and throw everything at the wall hoping that something sticks. More skilled / experienced entrepreneurs do do a bit of that, but they’re more deliberate about it. (They might not tell you that they’re being deliberate; if you ask them they’ll look at you funny and go “that’s dumb, why would I want to make that bet without doing some thinking beforehand?”)

The PR/FAQ process is used for big, one-way door type bets. Most new product attempts are costly, and can lock up company resources for months if not years. You’re not getting that time back. The more costly the bet, the more rigorous the PR/FAQ process. The less costly the bet, the more likely the executives would say something to the effect of “Bias for Action” — just go and do it.

My understanding is that the concepts of ‘one-way vs two-way doors’ was invented to illustrate this dynamic … amongst other things.

To add a concrete example of my application of these ideas:

  1. I’m currently working out a sustainable and repeatable way to hire case writers. Hiring writers in the context of a summer internship and getting it wrong is cheap, so I just went ahead and hired a bunch without writing a PR/FAQ.
  2. We know from our WBR that one thing that results in exceptional variation across a number of metrics we care about is getting a link from a sizeable newsletter / Substack. But we need to run a set of experiments to figure out what types of Substacks are best (size? topic? familiarity?). Running these experiments require purchasing newsletter ads, that can (and has!) cost us thousands of dollars per ad. We have a full 6-pager for that.
5 Likes
10

@cedric Revisiting this topic because I’m putting PR/FAQ into practice for a side project that me and my friend is building. Here’s the part from Putting Amazon’s PR/FAQ to Practice that I’m interested in:

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

I believe we’ve figured out who are the customers and what problem we’d be solving, but we’re a bit uncertain about the solution space, i.e whether the solution we’re thinking of would indeed solve their problems. In this case, we get stuck when describing the product because it’s just assumptions - which the PR/FAQ process made clear.

I might sound like a “every dumb software founder”, but it seems the only way to know about this for sure is to build a solution and get feedback. Typically the most difficult thing (in my experience) with discovery is to discover the right solution, and I wonder if it’s possible to arrive at this through iterating over the PR/FAQ, as opposed to building an MVP?

Or to ask about your direct experience, when you wrote this:

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

Was this clarity a result of iterating over some PR/FAQs, or was it because you already had clarity on what to build that writing the PR/FAQ felt easier?

1 Like
11

Wait, how can you get stuck when describing the product ‘because it’s just assumptions?’ In my experience, all the assumptions are typically about the problem and the customer. The solution is rarely bottlenecked by assumptions, because you can make tradeoffs as you’re writing the PRFAQ and making up the solution (constrained by the fact that it must make sense and be compelling to a potential customer).

If you can’t make the solution sound compelling in a PRFAQ, you shouldn’t continue.

Hmm — no, the clarity came from understanding the customer and how they saw Commoncog and what they wanted out of Commoncog.

2 Likes
12

Right, I think what I meant is probably that there are a few assumptions about customer behaviors that we’re not certain of.

For example, in the case of Amazon Prime, in the end it turned out that consumer behavior change followed what Bezos predicted (not that this side project is anywhere near that scale), but in the beginning it was not obvious at all:

By 2007, two years after launch, internal data finally showed that on average, customers who joined Prime doubled their spending on the site. Bezos’s predicted consumer behaviour change had finally turned up. And perhaps it shouldn’t be so surprising that it took this long — if your customers shopped online only a few times a year, it would take a few years before the overall trend became clear.

1 Like
13

In the Amazon Prime case, the PR FAQ for the offering was compelling to the customer, they understood the customer well, and the need for the program was existential. The big unknown was whether they could do it without bankrupting the company. But from talking to Colin, most of the execs knew (because of their WBR, which gave them a finger tip feel of the customer) that the bet was very plausible on the customer end — in the sense that the behavioural change was likely to take (recall there were precursor programs, so it wasn’t like they were completely in the dark)

I think a better example for your point would be the Fire Phone, where the folks involved believed the product was compelling to the customer, but it turned out not to be.

I think the answer here is that your PRFAQ should pass the plausible test for everyone who reviews it. After which you shoot your shot. It doesn’t guarantee success. But it does save you from making incoherent bets.

Also related:

2 Likes
14

Sorry @minhthanh3145 to clarify I meant that if you shoot your shot and it turns out your proposed solution fails because it’s not compelling, then what happens is your taste improves.

But in general I think most (?) folks working in a domain will eventually build taste for what they think their customers want. And with that lens, you could say that Amazon didn’t have good intuition for what customers would like in the Fire Phone because nobody had made a phone before.

2 Likes
15

Thanks for the clarification, that makes sense. To acquire taste is, I think, to articulate your hypothesis about why it might work (which the PR/FAQ helps by forcing us to think from a customer perspective), then try something out to see if it works as expected. If it fails then you might learn something new to refine your hypothesis & intuition. Looking at it this way, it seems much closer to the Lean Startup that I know.

1 Like