Iterating PR/FAQ Documents Through Feedback

How to revise a PR/FAQ across rounds of review, from a solo draft to an executive decision, and how to tell when the document is ready to decide on.

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

A PR/FAQ is written to be rewritten. In the Working Backwards method, the first draft is where the thinking starts, and most of the value comes from the rounds of critique and revision that follow. Colin Bryar and Bill Carr write that it is not unusual for an Amazon team to write ten drafts of the PR/FAQ or more, and to meet with their senior leaders five times or more to iterate, debate and refine the idea (Amazon's excerpt from Working Backwards).

The drafts change in character as they go. Early on the document is a solo effort, usually by a product manager, and it has holes the author has to research to fill. As more blanks are filled in, the author asks a manager and a few cross-functional peers for feedback, then takes it to a first review with a small cross-functional group and a decision maker. When that decision maker is satisfied, the document goes to the appropriate executives, and if they find it promising, more drafts and reviews follow (PR/FAQ instructions).

The iteration is where weak ideas stop and strong ones get sharper. Bryar and Carr describe the process as creating a framework for rapidly iterating and incorporating feedback. They also note a side effect: leaders who review many PR/FAQs get better at spotting omissions and flaws, which strengthens every later review (book excerpt).

Iteration takes time, and the authors do not hide it. They write that the most successful products at Amazon required months of work before the PR/FAQ was finalized and the team was hired, and that the early AWS team spent more than a year writing, revising and debating its PR/FAQs (PR/FAQ instructions). Their argument is that time spent getting direction right is what lets the team move fast once building starts.

This skill covers the sequence of drafts and reviews and how to manage them. Running any single review meeting is covered in Running PR/FAQ Review Meetings.

How It Works

Each round has an audience and a question. The early solo drafts answer whether the author can describe the customer, the problem and the solution at all. The manager and peer round answers whether the idea survives people who know the area. The small-group review, with about 10 contributors for the first few drafts in the authors' description, tests the idea across functions (PR/FAQ instructions). The executive reviews test whether the idea is worth the company's resources compared with everything else competing for them.

Feedback is processed in writing. After each meeting the author sends minutes with notes on the feedback, then revises, and when the document is polished it goes to executive leaders, where there will be more feedback and possibly more revisions and meetings (book excerpt). Keeping a log of each piece of feedback and what changed makes later reviewers trust that earlier concerns were handled.

Revisions should get the document closer to the truth. Bryar and Carr warn against using the PR/FAQ to sell an idea to win approval and budget, and suggest asking what needs to be true for the product to succeed and how the team will address each barrier (PR/FAQ instructions). A revision that answers a hard question with evidence moves the document forward. A revision that softens the question so it no longer looks hard moves it backwards.

Good revisions take time away from the document. Bezos wrote that great memos "are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind," and that a great memo probably should take a week or more (2017 letter). Scheduling the next review too close to the last one leaves no room for that.

The iteration ends in a decision. Bryar and Carr describe a point where the document is complete enough for a go or no-go decision, and they list what happens after a no: the idea is not differentiated enough, the market is too small, the investment is too high or risky, an unsolved problem remains, or the idea must wait its turn behind a backlog (PR/FAQ instructions). Ready does not mean certain. Bezos argued that most decisions should probably be made with somewhere around 70% of the information you wish you had (2016 letter).

The document keeps changing after approval. The authors describe the PR/FAQ as a living document that will almost certainly still be edited, and advise planning on many revisions even after the project has formally started (book excerpt).

Step-by-Step Guide

Step 1: Fill the holes in the solo draft

Before anyone else reads the document, list every blank and guess in your first draft and research the ones you can. Check the press release against the template and the FAQ against the standard questions. Mark the remaining unknowns clearly. Set the draft aside for a day or two, then reread it and cut.

Step 2: Get a first read from your manager and peers

Share the draft with your manager and a few cross-functional peers and ask a narrow question: do the customer and the problem hold up? Collect their comments in the document. Fix what changes the premise first, and start a feedback log that records each comment and what you did about it. If the customer or problem does not survive this round, rewrite the press release before going further.

Step 3: Run the small-group review

Hold a review with a small cross-functional group and a decision maker, using the silent-reading format. Make sure finance, engineering and any function that will carry real work are in the room. Send minutes afterwards and add every point to the feedback log. Expect the internal FAQ to grow and change most in this round.

Step 4: Revise for substance before wording

Sort the feedback into changes to the customer, the problem, the solution, the economics and the wording. Work in that order, because a change to the customer can make wording fixes pointless. Update the press release and FAQ together so they stay consistent. Record in the log what changed and why, including feedback you chose not to act on and your reason.

Step 5: Repeat until the decision maker is satisfied

Hold further small-group reviews as needed, leaving time between them for real revision. Invite new reviewers when a new area becomes important, such as legal once a regulatory question appears. Watch the kind of feedback each round produces: when it shifts from structural problems to refinements, the document is close to ready for executives.

Step 6: Take it to the executives

Once the small-group decision maker is satisfied, take the document to the executives who control the resources. Include the feedback log or a short summary of how major concerns were resolved. Expect new questions at this level about priority and investment. Repeat the revise-and-review cycle if the executives find the idea promising and want more.

Step 7: Close with a decision and keep the document alive

When the document can support a go or no-go decision, ask for one. If the answer is go, the FAQ should already describe the resources and rough timeline, and the PR/FAQ becomes the reference for the project and keeps being updated as it changes. If the answer is no, record the reason and what would need to change for the idea to return, and file the document where it can be found.

Best Practices

• Keep a feedback log from the first review. It shows reviewers their concerns were heard, prevents the same argument happening twice, and records why decisions were made.
• Change the press release when the FAQ changes the product. A PR/FAQ whose two halves disagree is harder to review than either half alone.
• Leave time between rounds. Revisions made the evening after a review tend to be patches; revisions made after a day or two away tend to be rewrites where needed.
• Add reviewers deliberately. Bring in a function when its question becomes important, and keep the early rounds small enough for detailed debate.
• Judge readiness by the kind of feedback. A round that produces only refinements is a sign the structure is sound.
• Let the document stop. If rounds keep exposing fundamental problems, recommending no-go is a successful outcome of the process.

Common Mistakes

• Fixing wording while the premise is in question: Polishing sentences in a document whose customer may change wastes a round. Resolve structural feedback first.
• Answering feedback in the meeting and not in the document: Spoken answers are forgotten by the next review. Every resolved question belongs in the FAQ.
• Rushing to the executive review: Taking a document to executives before the small group is satisfied spends scarce executive attention on problems peers would have caught.
• Iterating forever: Endless revision can become a way to avoid a decision. When feedback turns into refinements, ask for the decision.
• Freezing the document after approval: Projects change once building starts. Keep the PR/FAQ current so it remains the shared reference for what is being built and why.

References

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

Related Skills

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

Sources

• About Amazon: excerpt from Working Backwards
• Working Backwards LLC: PR/FAQ Instructions and Template
• Jeff Bezos: 2017 Letter to Shareholders
• Jeff Bezos: 2016 Letter to Shareholders

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