How marketing supports the PRFAQ process

A PRFAQ is a mock press release plus a list of frequently asked questions, written before you build the product. Here's the part teams forget: it's a starting document, not a final one. It exists to align everyone on the customer and their pain before a line of code gets written. Marketing rarely owns the document, but it has a useful job in the process: keeping the language customer-centric, so the team stays pointed at the customer instead of at a product it has already decided to ship.

I've been reading a lot of PRFAQs lately, all built on Amazon's working-backwards method. The method is good. The trouble is that most drafts read like the announcement of a thing the team is going to build, not the description of a customer and the problem they live with. That one shift in language changes what the document is for.

What is a PRFAQ actually for?

A PRFAQ is a thinking tool, not a launch asset. Amazon's working-backwards method, described by CTO Werner Vogels in 2006, tells you to "start with your customer and work your way backwards" by writing the press release and FAQ before you build. Most of Amazon's major products since 2004 have started this way. The document's job is to prove the customer's problem is real and worth solving.

The format is deliberate. Ian McAllister, who ran product teams at Amazon, published the template: a headline that announces the product, a subhead, and then a problem section ranked by how much each problem hurts. The headline does what a press release headline is supposed to do, which is land what's happening. The pain shows up right underneath it. Colin Bryar and Bill Carr, both longtime Amazon VPs, wrote the book on it, with a simple test: if the press release doesn't make a reader say "wow, the customer really wants this," stop and start over.

None of that is the problem. The headline announces, which is its job. The method exists to force customer-first thinking before anyone writes code. The trouble starts when teams forget that and treat the document like something else.

The trap: writing a starting document like a final one

The most common failure isn't the format. It's forgetting what the document is for. Teams write the PRFAQ like the real launch announcement, the one you publish after you've shipped. The language gives it away. It describes a thing and its features instead of a customer and their pain. "Acme introduces Branch Deploys. It spins up isolated database copies."

Once the document is about the thing, every decision downstream bends toward the thing. The team stops asking "what does the customer need?" and starts asking "how do we justify what we already decided to build?" The PRFAQ was supposed to keep you honest. Written product-first, it does the opposite. It launders a preconceived product into something that looks customer-driven.

The tell is always the language. Read the draft and ask what it's about. "This is the customer. This is their pain. This is how they think" is a starting document. "This is the thing we're shipping" is a press release you wrote too early.

Why customer-centric language rallies the team

Here's why the language matters more than it looks. A PRFAQ written from the customer's pain immortalizes for the team what they are fighting for. It aligns everyone on the goal instead of boxing them into a product or a brand. That is how you get customer-led product development: the whole team knows who they are building for and what hurts, so the hard calls get made in the customer's interest.

A PRFAQ written from the product does the reverse. It hands the team a conclusion and asks them to reason back to it, which is the opposite of what working backwards means. Decisions start serving the roadmap. The customer becomes a justification rather than the point. Months later, nobody can remember who the thing was for, because the document never really said.

This is the whole reason to write a PRFAQ before you build. Not to pre-write the launch, but to give everyone a customer to rally around while the decisions are still open.

What does marketing bring to the PRFAQ?

Supporting the PRFAQ process is more than proofreading it. Marketing brings three things the author often can't supply alone: the customer's actual language, the swap test, and the real customer pain gathered from the people who hear it. The product manager knows what the feature does. Marketing knows the words a customer uses for the problem, and those are rarely the same words.

The customer's language. Whether or not the headline announces the product, the pain underneath it has to sound like a customer, not a brief. That language comes from positioning, which I argued still matters in does positioning still matter.

The swap test. Take the document and replace your company's name with a competitor's. If it still reads fine, you've described a product anyone could announce, not a customer only you understand. I made the same case about generic messaging in every AI product sounds the same.

The real pain, from the people who hear it. The customer quote and the "what they do today" paragraph are the hardest parts to fake, and they're rarely one person's to write. Support sees what breaks. Customer Success hears what almost made someone churn. Sales knows what a prospect used before, and why they switched or why you lost them. Marketing pulls those threads together. A fabricated quote reads like marketing wrote it, and a made-up "what they do today" falls apart the moment someone who has talked to a customer reads it. So talk to the people who have, and if the research isn't there, go get it first. Shaping that point of view is a big part of what product marketing does.

How do you keep a PRFAQ customer-centric?

When you review a PRFAQ, judge the language, not the layout. Ask whether it describes a customer or a product, whether the pain sounds like a real person, whether the quote is believable, and whether the team would know who they are fighting for after reading it. The language is the fastest tell of whether the customer thinking happened or got skipped.

• Is it about the customer or the product? If it reads like a feature list, it isn't ready.
• Does it survive the swap test? Replace your name with a competitor's. If it still works, you've described a product anyone could ship.
• Is the customer quote believable? A fabricated quote reads like marketing wrote it. Pull a real one from Support, Sales, or Customer Success.
• Would the team know who they're fighting for? If they wouldn't, the document isn't doing its job as a starting point.

One caution. Don't turn this into a fill-in-the-blank template. The moment you mandate a rigid sentence, authors backfill it and you get customer-washing: the same product-first thinking with the customer language bolted on. Mandate the thinking, and read the language as evidence of whether it happened.

Here's a side-by-side example

Same product, same Amazon format, two different documents. The left column reads like a thing the team has decided to ship. The right column reads like a customer the team is fighting for. Both announce the product in the headline, the way a press release should. Read each as a short PRFAQ for Acme's mythical Branch Deploys.

Product-first draft	Customer-first rewrite
Headline. ACME ANNOUNCES BRANCH DEPLOYS, DATABASE BRANCHING FOR EVERY PULL REQUEST	Headline. ACME ANNOUNCES BRANCH DEPLOYS SO DEVELOPERS NEVER TEST ON PRODUCTION AGAIN
Subhead. A new feature that spins up isolated copies of your database on demand.	Subhead. For every team that has shipped a change that passed all its tests and still broke production.
The problem. Teams need isolated environments to test their changes.	The problem. The only place to test against real data is the database your customers depend on, so teams test on production and hold their breath.
The product. Branch Deploys creates a copy of the database for each pull request and deletes it on merge, built on Acme's branching engine.	The product. Branch Deploys gives every pull request its own copy of the production database, so you test against real data without risking the real thing.
Customer quote. "Branch Deploys has completely transformed how our team ships software."	Customer quote. "We used to clone the database by hand every Friday before a big merge. Now every pull request just has its own. We stopped dreading deploy day."

Both announce Branch Deploys. Only the right column gives the team a customer to fight for, and that is the whole reason to write the document before you build.

Get that right and the PRFAQ does its real job. It points the team at a person and a problem, so the decisions that follow serve the customer instead of a product someone already picked. Save the "here's what we shipped" version for the real launch post, once the customer has told you it was worth building.