Drafting the FAQ Section of a PR/FAQ

How to write the external and internal FAQs of a PR/FAQ so they test the press release against customer doubts, costs, risks and open problems.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The FAQ is the second and longer half of a PR/FAQ, the document at the center of the Working Backwards method. The press release says what the product is and why a customer would want it. The FAQ works out what it would take to deliver that, and whether it is worth it. Colin Bryar and Bill Carr describe the split this way: the press release gives the highlights of the customer experience, and the FAQ gives the salient details plus a clear-eyed assessment of how expensive and challenging the product will be to build (Amazon's excerpt from Working Backwards). They cap it at five pages or less.

The FAQ has two sections. The external FAQ answers questions customers and the press would ask, such as how it works, what it costs, and how to get help. The internal FAQ answers questions from senior leaders and every department: finance, marketing, customer support, operations, HR and others. It also covers the hard problems that must be solved to build the product, whether technical, financial, legal or operational (PR/FAQ instructions).

Bryar and Carr use a metaphor for the relationship. A good press release defines a destination with a treasure, and "Think of the FAQ section as the map to that destination and a detailed description of the dragons you will need to slay along your journey." The FAQ is where an attractive idea meets its costs, and where most ideas that should stop do stop.

Amazon's CTO described the same step in 2006 as adding meat to the skeleton of the press release, with questions that came up while writing it, questions other people asked when it was shared, and questions that define what the product is good for (Werner Vogels, Working Backwards). That is a practical way to collect questions: keep a list while you write the press release, and add every question reviewers raise.

The tone matters. The authors want an FAQ that is "optimistic but also realistic," one that shows the authors are not in love with their own idea. A good FAQ includes a data-based assessment of the market, a firm grasp of what building the product requires, the risks, and the conditions under which the product would succeed or fail.

How It Works

The external FAQ is a conversation with the customer in plain language. Bryar and Carr's standard external questions are short: what is the price, how does it work, how do I get help or support, and where can I buy it (PR/FAQ instructions). Add the questions your specific customer would ask: whether it works with what they already use, what happens to their data, how they switch from the current solution. The answers have to be as concrete as the press release, since vague answers here usually mean the product is not yet defined.

The internal FAQ is longer and harder. The authors' standard list works through a sequence of questions that a skeptical leader would ask:

• Customer and problem: what customers use today, what problem this solves, and in what way the product is better, cheaper or faster than the alternatives.
• Market: how large the demand and the total addressable market are, how many people have the problem badly enough to pay to solve it, and how many can actually use the product.
• Hard problems: the business model, engineering, legal and UI problems that must be solved, the new capabilities needed, and dependencies on partners and third-party technology.
• Economics: per-unit economics, the upfront investment in people, technology and inventory, how that risk will be managed, and how long until the product is profitable.
• Assumptions and failure: what must be true for the product to succeed, and the top three reasons it will not succeed.

Not every question applies to every product, but skipping one should be a decision. The authors also warn against discounting the competition: "there is always a current solution," so the FAQ should say whether the product is compelling enough for customers to switch. They suggest asking "What needs to be true for this product to be successful?" to keep the document focused on finding the truth instead of winning approval.

Unknowns belong in the FAQ, stated as unknowns. An answer that says the team does not yet know, and explains how it will find out, is more useful to a decision maker than a confident guess. Each open question becomes work before the next review or a condition on the decision.

Complicated products can need more than one FAQ. The authors note that Fulfillment by Amazon was developed with two PR/FAQs, one from the seller's point of view and one from the buyer's. If your product serves two very different customers, consider separate documents instead of one FAQ that tries to answer both.

Step-by-Step Guide

Step 1: Collect the questions

Reread the press release as a skeptical customer, then as a skeptical finance lead, then as the engineer who has to build it. Write down every question each would ask, without answering yet. Add the questions you noted while writing the press release and any that early readers raised. Start from the authors' standard list and cross out only the questions that clearly do not apply.

Step 2: Write the external FAQ

Answer the customer questions first, in the same plain language as the press release. Cover price, how it works, where to get it, support, compatibility with what the customer uses today, and what happens to their data. Keep each answer short and specific. If an answer needs a paragraph of caveats, the product definition probably needs work.

Step 3: Write the internal FAQ on customer and market

Answer who has the problem, what they use now, and why they would switch. Estimate the size of the market and show how you got there, including the assumptions. Say how the product is better, faster or cheaper than the alternatives, and be honest if it is only better on one dimension. These answers decide whether the rest of the FAQ is worth writing.

Step 4: Write the internal FAQ on building and economics

Answer what must be built, which problems are unsolved, which partners or third-party technologies you depend on, and what legal or regulatory issues apply. Then answer the economics: per-unit costs and margins, the upfront investment, and when the product would pay back. Get engineering, legal and finance to check their sections before any review. Name the parts that are estimates.

Step 5: Write the failure questions

Answer "what needs to be true for this product to be successful" with a short list of assumptions. Then answer the top three reasons the product will not succeed. These two answers are the most useful part of the FAQ for a decision maker, because they show where to look for risk. If they are easy to write, you have probably been too gentle with the idea.

Step 6: Mark the unknowns

Go through every answer and label the ones that rest on guesses. For each, say what would resolve it and when. Do not hide unknowns inside confident prose; reviewers will find them, and finding them in the meeting costs more trust than listing them yourself.

Step 7: Order, cut and circulate

Put the external FAQ first and order internal questions from the most decision-relevant down. Cut answers that repeat the press release, and keep the whole FAQ within five pages. Circulate the draft for review, following Running PR/FAQ Review Meetings, and add every new question reviewers raise.

Best Practices

• Answer the hardest question first while you still have energy. The top three reasons the product will fail often reshape the rest of the FAQ.
• Show your reasoning for every estimate. A market size or cost with its assumptions written out can be corrected in review; a bare number can only be believed or doubted.
• Name the current solution in every competitive answer. Customers always have some way of dealing with the problem today, even if it is a spreadsheet or doing nothing.
• Get each department's questions from someone in that department. The questions finance or legal will ask are hard to guess from outside, and asking early brings them into the process.
• Keep a question log as you go. Every question raised in a review should appear in the next draft with an answer or an open marker.
• Write for a reader who missed the meeting. Answers should stand alone without verbal context.

Common Mistakes

• Writing only easy questions: An FAQ full of questions with flattering answers looks complete and tells reviewers nothing. Include the questions you would least like to be asked.
• Answering with assertions: "We believe this is feasible" gives a reviewer nothing to check. Give the reason, the evidence, or the spike that would provide it.
• Hiding unknowns: Confident answers built on guesses collapse in review and damage trust in the rest of the document. Label guesses and say how you will resolve them.
• Letting the FAQ grow without limit: Long FAQs push the real issues into places nobody reads. Cut to what a decision maker needs and keep the rest in an appendix or elsewhere.
• Leaving the press release unchanged: If the FAQ uncovers that the product must change, the press release has to change too, or the document contradicts itself.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Working Backwards

Related Skills

• Writing an Internal Press Release for a Product Idea
• Running PR/FAQ Review Meetings
• Iterating PR/FAQ Documents Through Feedback
• Identifying Minimum Lovable Requirements
• Defining the Customer Experience Before Building
• Using Working Backwards in PM Interviews

Sources

• Working Backwards LLC: PR/FAQ Instructions and Template
• About Amazon: excerpt from Working Backwards
• Werner Vogels: Working Backwards

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.