Product Documentation (PRD, PR/FAQ) Questions
Writing the artifacts that align teams and drive decisions: PRDs, one-pagers, and the PR/FAQ (working-backwards) format. Covers document structure and clarity, the press release lead, the external and internal FAQ, hard-question answers, success metrics and acceptance criteria, engineering-ready requirements and constraints, and reviewing or pressure-testing a draft. Also covers using written narrative to sharpen thinking and secure buy-in across functions, and running PR/FAQs as a team practice: intake and review process, versioning, onboarding and co-creation workshops. Assesses written product communication and documentation strategy.
How would you write concise acceptance criteria for a cross-platform 'dark mode' feature in a PRD so designers, QA, and engineers can implement and test it? Provide five specific criteria that are testable across web and mobile.
Sample Answer
Direct answer
Good acceptance criteria are short, observable statements of the form Given (starting state), When (action), Then (verifiable result), each testable by QA (quality assurance testers) on web and on iOS/Android without asking the author what it meant. For dark mode I would pick five that cover: theme choice, persistence, contrast, no wrong-theme flash, and coverage of every surface. Each names how it is checked so designers, QA and engineers read the same requirement.
The five criteria (criteria 1 and 5 each bundle two related checks, so treat them as five topics and about seven checks; criterion 5 is the core one, because it stops the feature being skin-deep)
Terms used below. Design tokens: named colour variables (such as text-primary) that every screen reads instead of typing colour codes, so one change updates the whole app. First paint: the first frame the user actually sees while a page or app is loading. Visual regression: an automated test that screenshots each screen and flags pixel differences from an approved image. End-to-end test: a script that drives the real app like a user would.
| # | Criterion | How it is tested |
|---|---|---|
| 1 | Theme choice. Given the Appearance setting, when the user opens it, then three options exist: System, Light, Dark, with System the default. Given System is selected, when the device theme changes while the app is open, then the app switches without a reload or restart. | Manual on web (browser and OS setting) and on each mobile OS; automated UI test toggling the OS setting |
| 2 | Persistence. Given the user picked Dark, when they close and reopen the app or the browser, then Dark is still applied on that device. | End-to-end test: set, restart, assert |
| 3 | Contrast. Given Dark is active, then text and background meet WCAG 2.2 AA (Web Content Accessibility Guidelines): at least 4.5:1 for normal text and 3:1 for large text and for icons and control borders. The ratio compares the brightness of the two colours: 1:1 is identical (invisible), 21:1 is black on white. | Contrast checker on the design tokens (named colour variables such as text-primary) and on screenshots |
| 4 | No wrong-theme flash. Given Dark is chosen, when a page loads or the app launches, then the first painted frame is already dark, with no flash of a light screen. | Web: throttled reload (page reloaded with the network deliberately slowed so a flash is easy to catch) plus screenshot at first paint. Mobile: cold-launch recording (screen-record the app starting from fully closed) |
| 5 | Coverage. Given Dark is active, then every screen on the agreed screen list (attach the list) uses theme tokens for its surfaces, text, icons and images, with no hardcoded white background, and system elements (status bar, keyboard, dialogs) match. | Visual regression on every screen in both themes; a code search for hardcoded colour values |
Worked example of why the wording matters
"Dark mode should look good" fails: two people disagree and neither can be shown wrong. "Text contrast at least 4.5:1" is testable: a checker reports 4.7:1 or 3.9:1, and the second fails the build. Concretely, on a #121212 dark background, grey text #8A8A8A measures about 5.4:1 and passes, while #777777 measures about 4.2:1 and fails, though the two greys look almost the same to the eye. Likewise, "works on mobile" becomes criterion 1's specific check on each OS.
Designer, QA, and engineer views
- Designers own the token values and the screen list; QA owns the test matrix (web on two browsers, iOS, Android, plus a screen-reader spot check); engineers own that colours come from tokens so criterion 5 is enforceable.
- Out of scope, stated explicitly: per-screen overrides, scheduled themes, and user-uploaded content, which may keep its own colours.
Pitfalls
- Testing only the screens designers remembered: the screen list must come from the app's route or screen inventory (the complete list of pages or screens exported from the codebase, not from memory).
- Images and charts with white backgrounds baked in, the usual cause of criterion 5 failures.
- Ambiguous theme defaults: say which wins when the OS is dark but the user chose Light.
How would you test the clarity and appeal of a PR/FAQ press release with potential customers before committing to building the product? Provide at least three distinct methods (qualitative and quantitative), explain how you'd run each, and list pros and cons for each method.
Sample Answer
Direct answer
I would use three methods in sequence: customer comprehension interviews (qualitative), a fake-door landing page test (quantitative behaviour), and a message A/B test or survey (quantitative preference). Together they answer two different questions: do people understand the press release (clarity) and do they want what it describes (appeal). No single method answers both.
The three methods
| Method | How I would run it | Pros | Cons |
|---|---|---|---|
| Comprehension interviews (qualitative) | Show 6 to 8 target customers the press release cold. Ask them to explain it back in their own words, then ask "who is this for?" and "what would you use it for?" | Reveals exactly which sentence confuses people; cheap and fast | Small sample; polite customers overstate interest |
| Fake-door landing page (quantitative behaviour) | Turn the press release into a landing page with a sign-up or "notify me" button for a product that does not exist yet (the honest follow-up says it is coming soon). Send traffic from the real customer channel and measure click and sign-up rates | Measures action, not opinion; cheap | Sign-up is not purchase; traffic quality changes results; needs enough visitors |
| Headline A/B test or survey (an A/B test randomly splits people into two groups that each see a different version) | Show two versions of the lead sentence to two randomly split groups and compare the share that click, or the share that correctly restate the benefit in a one-question survey | Compares versions with numbers; scales | Needs a decent sample; measures the wording, not the product itself |
Worked example
A comprehension test with 8 customers: 5 say the product "orders groceries for me", 3 think it is "a fridge camera". Eight people are too few to trust a percentage. The finding is that the second group reads the word "smart" as a camera. Change the headline and retest (run the same test again after the change) with a fresh 8. Then run the landing page: with 500 visitors and a pre-agreed pass bar of 5% sign-up, 25 or more sign-ups counts as a pass. All numbers are illustrative; the bar must be set before the test.
Trade-offs and pitfalls
- Using the same customers for the retest after showing them the first version.
- Reading a small A/B difference as a winner. With few visitors, a 2-point gap is often noise; agree the sample size first.
- Testing appeal on internal colleagues.
- Deceiving customers. A fake-door page should not take money or promise delivery dates it cannot keep.
Explain the PR/FAQ framework. What is the press release for, what is the companion FAQ for, and how do you decide what belongs in each?
Sample Answer
Direct answer
A PR/FAQ is a pair of documents written before building. The press release (PR) is the imagined public announcement: it tests whether the product is valuable and clear to a customer. The FAQ (frequently asked questions) is the companion where the hard, uncomfortable questions get honest answers, both what customers would ask and what leadership, engineering, legal, finance and support would ask. Rule of thumb: if it sells the customer benefit, it belongs in the press release; if it defends or qualifies the idea, it belongs in the FAQ.
What goes in each
| Press release (about one page, customer voice) | FAQ (a few pages, honest voice) |
|---|---|
| Headline: product name and the benefit | External: pricing, availability, how it works, cancellation |
| One-line summary for the target customer | Internal: cost, staffing, risks, dependencies, legal and privacy |
| The problem, in the customer's terms | Technical considerations and what we chose not to do |
| The solution and top benefits | Success metrics and how we will measure them |
| A customer quote and a call to action | Hard "why will this fail?" questions |
| Use case in a sentence or two | Alternatives considered and why we rejected them |
How to decide where something belongs
- Would a customer read it in an announcement? Press release.
- Does it need caveats, numbers, or trade-offs? FAQ.
- Does it read like internal logistics (headcount, architecture, margins)? Internal FAQ.
- If it is jargon a customer would not understand, it fails the press release test and moves down.
Worked example (a hypothetical "family calendar sync" app)
- Press release lead: "Today Hearth announced Family Sync, which puts every family member's events on one shared calendar in seconds."
- External FAQ: "Does it work with the calendar I already use?" "Is it free?"
- Internal FAQ: "What does it cost per active family to run?" "What happens to children's data (privacy law, consent)?" "Which team supports it?"
- A note on the lead: the conventional press-release template names the company and product in the headline and first sentence, so the example above follows it. The benefit still arrives in that same sentence. A customer-first version ("Families can now see everyone's events on one shared calendar in seconds") is a stronger test of value, because it survives if you delete the product name.
When the format is worth using
- New products or major features where the customer value is unproven.
- Cross-team efforts needing a shared vision.
- Not worth it for small fixes, routine updates or bug work; a one-page brief is enough.
Pitfalls
- Putting technical detail in the press release.
- Hiding hard questions by leaving the FAQ soft.
Compare PR/FAQ to a traditional PRD (Product Requirements Document). List three concrete differences in format, primary audience, and intended outcome. Give one scenario where PR/FAQ is the preferable artifact and explain why.
Sample Answer
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
| PR/FAQ | Traditional PRD | |
|---|---|---|
| Format | Narrative prose: a one-page press release plus a question-and-answer FAQ | Structured sections: user stories, requirements, acceptance criteria, mocks, tables |
| Primary audience | Decision makers and cross-functional reviewers who must approve investment | Engineers, designers and QA who must implement and test |
| Intended outcome | A go/no-go decision and a shared customer vision | A buildable, testable contract of scope |
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.
Describe the core components you would include in a one-page product brief for a new feature. Include fields for problem statement, target users, success metrics, assumptions, non-goals, risks, and launch criteria, and explain why each field matters.
Sample Answer
Direct answer
A one-page product brief is a compact plan a busy reader can approve or challenge in five minutes. Each field forces one decision to be made in writing. I would include the seven fields you named in this order, then a short header (owner, date, status).
Fields, in order, and why each matters
| Field | What goes in it | Why it matters |
|---|---|---|
| Problem statement | Who has what problem, with one piece of evidence | If the problem is not agreed, everything after is opinion |
| Target users | The primary segment and who is excluded | Prevents building for everyone and satisfying no one |
| Success metrics | Metric, current baseline, target, date | Makes "did it work?" answerable |
| Assumptions | Beliefs we are betting on (e.g. "users will grant location access") | Turns hidden guesses into things we can test first |
| Non-goals | What we deliberately will not do | The cheapest tool against scope creep |
| Risks | What could go wrong, likelihood, mitigation | Lets reviewers spot what you missed |
| Launch criteria | Conditions that must be true to ship | Gives a clear go/no-go rather than a feeling |
Worked example: "reminder to finish incomplete profile"
- Problem: 38% of new users leave their profile blank, and blank profiles get fewer matches (illustrative internal figure).
- Target users: new sign-ups in their first 7 days. Not existing users.
- Success metric: profile completion in 7 days, baseline 62%, target 70% within two months.
- Assumption: a reminder email will not drive unsubscribes above the current rate.
- Non-goal: profile redesign.
- Risk: reminder fatigue. Mitigation: at most two reminders.
- Launch criteria: no rise in unsubscribe rate in a 10% rollout and support has an FAQ entry.
Pitfalls
- Success metrics without baselines.
- Risks that are vague ("timeline risk") instead of specific.
- Launch criteria that cannot be measured.
- Growing past one page: the constraint is the feature.
Unlock Full Question Bank
Get access to all 8 Product Documentation (PRD, PR/FAQ) interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.