Product Documentation (PRD, PR/FAQ) Questions

Direct answer

I would prove ROI (return on investment: benefit relative to cost) by treating PR/FAQ adoption as an experiment, not a memo: measure cost and three outcomes (wasted engineering time, feature success, decision speed) against a baseline, and use a staggered rollout so teams not yet adopting act as the comparison group. Then I would present a range with the assumptions visible, and pair numbers with qualitative signals. Attribution is the hard part, so I state up front what the data can and cannot prove.

KPIs (key performance indicators), with precise definitions

Qualitative: a short quarterly survey (are requirements clearer, do reviewers find the FAQ useful), sampled interviews with engineers and executives, and a review of whether the hardest FAQ questions matched what later went wrong.

Attribution: staggered rollout and comparison

Pilot teams adopt in the first half; comparable teams adopt in the second half. Compare the change in the pilot group to the change in the not-yet-adopters over the same period (a "difference in differences"), which removes company-wide trends like a new planning process or a good quarter.

Worked example (illustrative numbers)

• Pilot teams: wasted-effort share falls from 24% to 14% (drop of 10 points).
• Not-yet-adopters over the same half-year: 24% to 21% (drop of 3 points, from other causes).
• Attributable change: 10 - 3 = 7 points.
• If the pilot teams total 800 engineer-weeks in the half-year, 7% of 800 = 56 engineer-weeks saved.
• Cost: 12 PR/FAQs at 3 person-weeks each (writing plus review) = 36 person-weeks.
• Net = 56 - 36 = 20 person-weeks in the first half, with the cost curve expected to fall as teams learn the format. Report this as a range, since each input is uncertain.

How the numbers get gamed, and guards

• Teams write PR/FAQs only for safe projects: track selection (share of projects needing one) and compare like with like.
• Redefining "wasted" or "success" after the fact: fix definitions before starting.
• Faster decisions by rubber-stamping: pair speed with the success rate so speed alone cannot look like a win.

Trade-offs and pitfalls

• With few teams, results are noisy; do not claim precision. Say "directionally positive, with these caveats".
• Some value is not measurable in a year (avoided bad launches never appear); use qualitative stories, labelled as such.
• Present to executives as decision, cost, benefit range, caveats, and what you would do next (expand, adjust, or stop).

Direct answer

The section is a short table where each row is a constraint from one area (billing, data storage, UX, meaning user experience), the current answer, a feasibility rating and a named owner who signs off. It must be answerable in one page, and every row needs an owner and a date, otherwise it is a list of worries. Example feature used below: letting a customer pause a subscription and keep their saved data for a limited time.

The template

Cross-Functional Constraints and Feasibility

Rating meanings. Green: answer is confirmed by the owner and nothing blocks build. Amber: a workable answer exists but one named item is unconfirmed. Red: no workable answer yet, so build cannot start.

One complete row (illustrative)

• Area: Billing. Answer: billing stops at pause date, no refund of the current period, resume restarts a fresh cycle. Rating: amber, because the tax treatment of a paused subscription is unconfirmed. To turn green: Finance confirms in writing, by 20 June, that no tax is due while paused. Sign-off: Billing engineering lead and Finance.

What must be included, and why

1. Who is affected: new versus existing customers, so migration cost is visible.
2. Money movement: anything that changes what a customer is charged, refunded or invoiced needs Finance, because it also affects revenue reporting.
3. Data lifecycle: keep, delete, restore. Storage size times retention is a cost you can estimate up front. Illustration: 50,000 paused accounts at 2 GB each is 100,000 GB, about 100 TB held for up to 90 days.
4. User-visible states and words: a paused customer must never be surprised by a charge or a deletion.
5. Open questions: each has an owner and a date, because an unowned question blocks estimation.

Sign-off rules

• One accountable signer per row, not a committee. Where the table names two functions on a row (for example Billing engineering lead and Finance), the first named owns the row and signs for its rating; the second is a required co-signer who confirms only their part (the money effect, the retention rule) and cannot hold the row open past the date set for it. Engineering manager signs the overall rating.
• A red row blocks the PRD (product requirements document, the spec of what to build and why) from moving to build until the owner and PM agree on a change or an exception.

Pitfalls

• Sign-off by presence in a meeting rather than by reading the row.
• Ratings with no reason. Every amber or red states what would turn it green.
• Skipping Support, who inherit the confusion when copy is unclear.

Direct answer

I write a short PRD (Product Requirements Document) built around a hypothesis. The reviewer should see, in order: the problem and the opportunity in numbers, for whom, the hypothesis, what is being built, the success metrics with guardrails, the experiment plan, and the risks. The hypothesis sits right after the problem and users (item 4), so the reviewer meets the bet before the detail, and the experiment plan sits right after the success metrics (item 7), so the test is judged against numbers already agreed. I leave out design minutiae and solution detail that does not affect the test.

Outline

1. Summary and decision needed (three sentences): what we are building, the expected impact, what we are asking approval for.
2. Problem and baseline: current conversion rate with definition and date range, and where users drop off in the funnel (the sequence of steps to purchase).
3. Target users: which traffic segment, and who is excluded.
4. Hypothesis: "If we show a delivery-date estimate on the product page, then checkout conversion will rise, because uncertainty about delivery causes abandonment."
5. What we are building: scope, non-goals, and requirements with acceptance criteria.
6. Success metrics: primary metric (conversion), a target, and a guardrail (a second metric that must not get worse while the main one improves, such as return rate or page speed).
7. Experiment plan: an A/B test (users randomly split into control and variant), split, duration, sample size rule, and the decision rule fixed in advance (the written-down condition for shipping, iterating or stopping).
8. Risks and dependencies: what could go wrong and mitigations.
9. Launch and rollback.

Worked example of the experiment section (illustrative)

• Baseline conversion is 3.0%. We commit to a 3.3% goal (10% relative lift, so 3.0 times 1.10 equals 3.3).
• Split 50/50, run for two full weeks to cover weekday and weekend cycles.
• Decision rule set before the test: ship if the variant beats control on conversion and return rate does not rise by more than the agreed tolerance (0.5 points in the written version below); otherwise iterate or stop.
• Sample size is computed with the data team before launch, not decided after seeing results. It depends on the baseline, the smallest lift worth detecting, and how sure we want to be. The usual two-proportion calculation (95% confidence, 80% chance to detect a real effect) gives roughly 53,000 users per arm for 3.0% to 3.3%, about 106,000 in total. Two weeks is enough only if about 7,600 eligible visitors arrive per day (106,000 / 14). If traffic is smaller, run longer or accept a larger minimum lift.

Hypothesis and experiment sections as they would read (illustrative)

Hypothesis: If we show a delivery-date estimate on the product page, checkout conversion will rise from 3.0% to at least 3.3%, because uncertainty about delivery causes abandonment.

Experiment: 50/50 split of product-page visitors for 14 days. Primary metric: checkout conversion. Guardrail: return rate within 30 days of purchase must not rise by more than 0.5 points versus control. Because that outcome matures 30 days after each user's order, we read conversion once, at the end of the 14 days, and read the guardrail once, 30 days after the last exposure (or use a shorter proxy such as 7-day returns if launch cannot wait). Decision rule: ship if conversion is above control at the pre-agreed sample size and the guardrail holds.

What I leave out

• Pixel-level design (linked mocks suffice).
• Implementation details, which belong in a design doc.
• Long market research, and metrics we will not act on.

Pitfalls

• Peeking at results early and stopping when they look good. Results bounce around by chance, so if you check daily and stop at the first good-looking moment, you will often stop on a random spike and ship a change that does nothing.
• A hypothesis with no mechanism ("it will improve things").
• Optimising conversion while return rate or support load quietly rises.

Direct answer

A PR/FAQ (Amazon's "working backwards" format: a one-page future press release announcing the outcome, followed by FAQs that stress-test it) for an acquisition differs from a greenfield one because you are not only asking "should customers want this?" but "should we buy a company, and can we absorb it?". I would add a deal thesis, an integration plan, and a due-diligence FAQ set (due diligence is the structured investigation a buyer runs on a company before signing, checking its finances, technology, contracts and people), and I would state walk-away conditions in advance. Recommendation: treat the FAQ as the diligence agenda, and let unresolved "red" answers block the deal rather than be explained away.

Extra sections beyond a greenfield PR/FAQ

1. Deal thesis: buy, build, or partner. Why acquiring beats building in-house (time, talent, data) or a partnership. Include the cost of delay, not just price.
2. Integration vision. Press release framed at integration day: "Customers of Platform X can now use [target capability] inside their existing account."
3. Integration options. Keep standalone, API-connect, or full re-platform (rebuild onto our stack), each with effort and risk.
4. Walk-away criteria. Findings that kill the deal (for example: core IP, meaning intellectual property such as code and patents, not owned by the company).
5. Post-close 12-month plan and success measures.

Risk FAQs by category (each FAQ needs an answer, an owner, and evidence)

What one entry looks like (illustrative)

• Acquisition press-release paragraph: "Today we completed the acquisition of LedgerLoop. Starting next quarter, our customers can automate invoice matching inside their existing account with one sign-in."
• FAQ entry: Q: "What share of revenue is at risk if the top customer leaves on change of control?" A: "35%, per the contract review; deal modeled without it." Owner: finance lead. Evidence: contract clause 14.2 and the revenue by customer report. Status: red until legal answers the waiver question.

Worked example (illustrative)

Target "LedgerLoop" (invoice automation, 40 people, 300 customers). FAQ: "What share of revenue would we lose if the top customer leaves at change of control?" Finding: top customer is 35% of revenue and its contract lets it terminate on ownership change. That is a red answer: model the deal with that revenue removed, and ask legal whether to seek a waiver (the customer's written agreement not to exercise that termination right) before signing. A second FAQ: "Who can we not lose?" Finding: one engineer holds the only knowledge of the billing engine, so retention terms for that person go in the deal terms and a 90-day knowledge-transfer plan goes into the integration plan.

Trade-offs and pitfalls

• Deal teams anchor on the vision and soften risks; assign a dissenting reviewer (a "red team") to write the hardest FAQs.
• Technical diligence done after price is agreed has no leverage. Sequence it before final terms.
• Integration cost is usually the underestimated line; force a range and state what would change it.
• Talent risk is real: acquired teams often lose people when integration disrupts their autonomy, so cover it explicitly rather than assuming it.

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.