Product Documentation (PRD, PR/FAQ) Questions

Direct answer

Run the workshop as a sequence of short, output-driven sessions: write silently and individually first, then merge, with a named decision-maker and a hard time limit on every disagreement. The goal for the day is a reviewed draft of the press release and the top ten hard FAQs with owners, not a finished document. Preparation before the day and capture right after it decide whether the workshop pays off.

Before the day

• 30-minute pre-read: the customer problem, evidence, and the rough idea, one page.
• Name the decider (the one person who breaks ties; in DACI terms this is the Approver) and share the ground rules. DACI is a common way to do this: Driver runs the process, Approver decides, Contributors give input, Informed are told the result.
• Invite each function with a lens: engineering (feasibility), design (experience), sales (customer promise), legal (risk), operations (running it).

Timed agenda (09:00 to 16:30)

Facilitation techniques to settle disagreements quickly

• Silent writing before discussion. Everyone writes their view first, so loud voices do not set the frame.
• Timebox and decide. A dispute gets 10 minutes; then dot-vote (each person places stickers on favoured options) or the decider chooses.
• Fist of five. Everyone shows 0 to 5 fingers for support. Anything below 3 must say what change would raise it.
• Disagree and commit: (agree to back a decision you argued against) a person may disagree, but once the decider decides, they commit to the outcome and their objection is recorded.
• Parking lot: off-topic issues are written on a board with an owner, not debated.
• Evidence first: a claim needs a customer quote, a data point or a stated assumption.

Capturing next steps and owners

A live decision log on screen with columns: decision, reason, owner, date. Action items are read back in the last session. Within 24 hours the facilitator sends the merged draft, the decision log and the action list; each action item has one owner, and a check-in date is set within a week.

Example go / no-go criteria: go only if (1) five of five interviewed customers described the problem unprompted, (2) engineering's rough size is under two quarters, and (3) no legal red flag is open; any "no" sends the idea back with a named owner and date.

Worked example of a dispute

Engineering says the feature cannot include real-time sync in the first release; sales says customers expect it. Ten-minute timebox: sales shows the three lost-deal notes, engineering states the cost (about a quarter of the team's time). Fist-of-five shows sales at 5 and engineering at 2 for including it. The decider chooses to ship near-real-time (updates within minutes) and adds an FAQ, "How fast do updates appear?". Engineering commits and the concern is logged.

Pitfalls

• Trying to finish the whole document in one day. Aim for a draft and owners.
• No named decider, which stretches every dispute.
• Skipping the follow-up: without it, the day's energy is lost within days.

Direct answer

Keep the press release as the single shared promise to the customer, then make the FAQ the coordination surface: a "who builds what" table, a dependency table, a commitments table, a rollout calendar, and a "what we are not promising" list, all in fixed positions. Ambiguity is the enemy, so each row names one owning team, one deliverable, a date and how completion is measured. Nobody builds against a misunderstanding if every dependency is a named row that the owning team has signed.

Structure

1. Press release (customer voice, one team-neutral story). One headline and benefit that every team agrees to.
2. Ownership table: who builds what. One owner per deliverable.
3. Interfaces and contracts. The required APIs (application programming interfaces: how one team's software calls another's) and data contracts (agreed field names, types, meaning and update frequency for data passed between teams).
4. Commitments with SLAs (service-level agreements: promised levels of speed and availability). What each provider team promises the others.
5. Rollout windows. Dates for each stage and who must be ready when.
6. Not promised and open questions. Each with owner and decision date.
7. Sign-off block. Every team lead signs their rows.

Plain-language terms used below: staging is a full copy of the production system used for testing before customers are affected; dogfood means our own employees use the feature first; a sprint is a fixed two-week work cycle (Sprint 6 means the sixth such cycle in the plan); the sponsor is the senior leader above all the teams involved; on call means the engineer currently responsible for answering urgent problems; an event contract is the agreed name and field list of a message one system publishes for another to consume; P95 means 95 of every 100 requests are at least that fast.

Worked example (illustrative): "one-tap checkout" across Payments, Identity and Notifications

Not-promised list and sign-off block for the same example:

• Not promised: saved-card management screens (owner: Payments, decision by Sprint 4); one-tap for corporate cards (owner: Identity, open question, decision by Sprint 5).
• Sign-off: Payments lead, Identity lead, Notifications lead each initial their rows and date them; an unsigned row is a blocker at the next review.

Rollout calendar: Identity ships first (Sprint 5), Payments consumes it in staging (Sprint 6), Notifications completes (Sprint 7), then employee dogfood, 5% of customers, 100%. The Ready by column doubles as the earliest date a consuming team can start against that row.

The FAQ rows that prevent misunderstanding:

• "What does Payments need from Identity, and by when?" (the token schema and Sprint 5).
• "What happens if Identity is late?" (the current checkout keeps running unchanged for customers; the one-tap release date moves to follow Identity's new date, and scope is not cut to hit the old date).
• "Which team answers a customer complaint about a missed confirmation?" (Notifications, with Payments on call for charge questions).

Trade-offs and pitfalls

• Too much detail turns the FAQ into a design doc. Keep interfaces to name, version, owner and link; put detail in contract documents.
• Vague verbs ("support", "integrate", "soon") are where misunderstandings live. Replace with a testable statement or a date. One rewrite: "Notifications will support order confirmations" becomes "Notifications sends the confirmation email within 60 seconds of a charge.succeeded event, and pages its on-call engineer if 1% or more are late for 10 minutes."
• A document nobody updates is worse than none. Give it one owner, review at each sprint boundary, and record changes as dated amendments.
• If two teams disagree on a row, the sponsor above both decides at the next review; the FAQ records the decision.

Direct answer

A PR/FAQ is a persuasion and discovery document written from the customer's viewpoint to decide whether to build something. A PRD (Product Requirements Document) is a specification written for the team to build it, listing requirements and acceptance criteria. PR/FAQ answers "should we, and would customers care?" while a PRD answers "what exactly do we build?"

Three concrete differences

A scenario where PR/FAQ is preferable

A company is deciding whether to launch a new paid tier for small businesses, and sales, finance and engineering disagree about whether customers will pay. Nobody yet knows the right features. A PRD would prematurely specify details of something that may not be worth building. A PR/FAQ forces the team to state the customer, the price and the hard questions in plain words, so the disagreement surfaces in review (for example, "why would a customer pay 20 dollars a month when the free plan exists?") before spending months of engineering.

When I pick the PRD instead

The direction is decided and the question is scope: a checkout redesign with agreed goals. The work is now coordination and testability, so I would write a PRD.

They are complements

A strong flow is PR/FAQ first to earn the go decision, then a PRD (or design doc) to drive delivery. The PR/FAQ does not replace acceptance criteria, and a PRD does not test customer value.

Pitfall

Treating a PR/FAQ as a marketing artefact, or writing a PRD to justify a decision nobody has actually interrogated.

Direct answer

Working Backwards is Amazon's product-development habit of writing the customer-facing announcement (a press release) and a list of hard questions (an FAQ) before any build starts, then judging the idea by whether that announcement is compelling. It starts from the press release because a spec describes what the team will build, while a press release forces you to say what the customer gets and why they would care. If the announcement sounds dull or confusing, the idea is weak, and finding that out costs a few days of writing instead of months of engineering.

How the process runs

1. Someone drafts the press release (commonly about one page) in plain language: the customer, their problem, the solution, and a customer quote.
2. They add the FAQ: external questions a customer would ask, and internal questions leadership, engineering, legal and finance would ask.
3. Reviewers read it silently, then mark it up. Iterate until the idea is either sharp or dropped.
4. Only then do detailed requirements and design start.

Why it changes the debate

Worked example: five FAQs for an automatic-reorder feature (a hypothetical Alexa household-supplies reorder)

1. How often will it reorder? (Customer: based on your usage, adjustable from weekly to quarterly.)
2. How do I turn it off or skip one order? (Customer: one tap, no penalty. Builds trust and answers support.)
3. What will it cost, and will the price change? (Customer and finance: same price as a normal order, no fee.)
4. What if I do not need the item any more, or it is out of stock? (Customer and operations: notify first, substitution only with consent.)
5. What data does it use, and how do we prevent accidental orders? (Legal and privacy: only order history you already generated; confirmation step for the first order.)

Notice how question 2 and 5 would never have surfaced in a feature spec, yet either can sink the launch.

Pitfalls

• Writing the press release as marketing hype instead of a test of value.
• Treating it as ceremony: a press release written after the design is decided proves nothing.
• Putting only easy questions in the FAQ.

Direct answer

I would add four things to the PRD (Product Requirements Document, the written agreement on what to build and how success is judged): a metrics section with baselines and targets, guardrails, a staged rollout plan, and a failure-modes table. Then I would present them as questions and offered drafts, in a conversation before any written comment, so the author feels helped rather than graded.

What I would propose

1. Success metrics. One primary metric with numerator, denominator, window and baseline (today's value, measured on a stated date), plus a target. Example: "share of new accounts that finish set-up in 7 days: baseline 41%, target 50%".
2. Guardrails. Metrics that must not get worse while the primary improves, with a stop threshold. Example: support tickets per 1,000 new accounts must not rise by more than 10% (illustrative).
3. Rollout plan. Staged exposure (internal, then 5% of users, then 25%, then all) with a check between each stage, plus a kill switch (a flag that turns the feature off without a new release) and a named owner who watches the numbers.
4. Failure modes. A short table: what could go wrong, how we would notice, impact, mitigation. Include data problems, performance, and a bad user experience.

How to present it without demotivating

• Speak first, write second: 20 minutes together, starting with what is strong in the draft.
• Ask questions instead of issuing verdicts: "What number would tell us in six weeks that this worked?"
• Bring a starter draft of the missing sections, so the author edits rather than starts from a blank page.
• Separate must-have (no success metric, no launch gate) from nice-to-have.
• Agree an owner and a date for each addition, and give the author the credit in the review notes.

Worked example

Draft says: "Improve onboarding" (onboarding means the first steps a new user takes to get set up and reach their first success). My proposed text: "Primary: 7-day set-up completion, 41% to 50% within 8 weeks of full rollout. Guardrail: tickets per 1,000 new accounts stay within +10%. Rollout: 5% for one week, review, then 25%. Failure mode: import fails for large files; detect via error-rate alert; mitigation: fall back to manual entry." (All figures illustrative.)

Trade-offs and pitfalls

• Dumping a comment list on the author in a public thread.
• Adding metrics nobody can measure yet. Check the analytics exist.
• Making the PRD longer instead of sharper. Every section should answer a question a reviewer would ask.